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ABSTRACT 


An  introduction  to  decision  logic  table  terminology* 
structure;  theory,  and  preprocessor  historical  development. 
Advantages  of  decision  tables  and  flowcharts  have  been  sur- 
veyed and  contrasted.  Techniques  of  decision  table  prepara- 
tion have  been  enumerated.  DELTRANS*  a  rule  mask  logic 
table  preprocessor  for  the  C  language*  has  been  proposed  for 
use  on  the  PDP-11/50  system  at  the  U.S.  Naval  Postgraduate 
School  . 
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INITIAL  DISTRIBUTION  LIST 141 


I.   INTRODUCTION 


A.   BACKGROUND 

A  decision  table  preprocessor  is  a  software  program  for 
translating  decision  logic  tables  into  compilable  source 
code.  The  preorocessor  developed  by  the  authors;  aptly 
called  DELTRANS»  was  desianed  to  operate  on  the  PDP-11/50 
system  at  the  Naval  Postgraduate  School  and  accept  C 
language  programs  containing  decision  logic  tables.  The 
design  o  *  DELTPANS  was  based  on  the  sequential  testing  rule 
mask  technique  perfected  by  Press  [<?0]  . 

The  use  of  this  decision  table  processor  should  reduce 
both  programming  effort  and  time.  The  additional  comDuter 
time  reguired  for  compilation  is  overshadowed  by  the  reduc- 
tion in  manpower  reguired  for  programming  both  during 
initial  programming  phases  and  maintenance  phases.  The  con- 
cept and  structure  of  decision  logic  tables  causes  the 
number  of  overlooked  situations  and  program  inconsistencies 
to  be  reduced. 

Decision  tables  offer  a  stimulating  alternative  to 
traditional  programming  methods  for  those  who  are  willing  to 
educate  themselves  in  their  construction  and  use.  With  this 
knowledge;  DELTRANS  is  but  another  tool  for  the  C  language 
programmer?  possibly  a  very  valuable  one. 


8 


The  major  steps  from  program  input  to  production  of 
executable  code  are  depicted  in  Figure  1.  Initially/  a  file 
containing  a  C  language  program  may  be  created  at  a 
terminal.  The  programmer  codes  those  segments  of  the  pro- 
gram not  covered  by  decision  logic  tables.  Special  symbols 
indicate  to  the  table  preprocessor  the  beginning  and  ending 
of  each  table.  Otherwise/  the  code  is  passed  unchanged.  At 
this  point/  a  call  to  DELTPANS  is  initiated  in  order  to  pro- 
duce compilable  source  code.  As  shown  in  Figure  1/  a  table 
listing  may  also  oe  obtained.  Subseauent 1 y /  normal  program 
compilation  may   be  accomo 1 i shed . 

Apoenaix  A,  the  DELTRANS  User's  Manual/  was  written  as 
an  independent  document  and  as  such/  guides  a  user  through 
the  steps  illustrated  in  Figure  1. 

B.   HISTORICAL  DEVELOPMENT 

I.   Development  of  the  First  Processor 


In  the  mid-195 Os/  General  Electric' s  Manufacturing 
Services  Department  initiated  a  research  effort  to  study  the 
manufacturing  orocesses  that  occur  from  the  receipt  of  a 
customer  order  through  the  production  of  the  finished  pro- 
duct. Having  recognized  that  comouters  might  play  a 
significant  role/  a  search  was  begun  to  find  a  satisfactory 
method  for  expressing  the  complex  logic  encountered. 


PROGRAM 
WITH  TABLES 


TABLE 
'LISTING 

(OPTIONAL! 


REMOTE 
TERMINAL 


TABLE 

PROCESSING 

STEP 


COMPILATION 
STEP 


FIGURE  1.   OELTPANS  Functional  Diagram 
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It  soon  became  apparent  that  available  methods  of 
describing  decisions?  such  as  formulas/  narratives?  and 
flowcharts?  were  inadequate.  The  efforts  of  the  project 
team  to  discover  a  new  method  of  expression  culminated  in 
the  development  of  "decision  structure  tables"  [183.  These 
tables  had  a  format  similar  to  the  truth  tables  from  which 
t  hey  originated. 

The  processor  for  solving  these  tables?  expressed  in 
a  language  called  7A8SOL?  operated  initially  on  an  IBM  702. 
Later  it  was  successively  implemented  on  an  IBM  305?  650? 
and  704.  In  early  1961?  an  improved  version  of  the  proces- 
sor and  TABSOL  were  implemented  on  the  GE  225. 

During  this  same  time  period?  Sutherland  Management 
Consultants  also  began  exoe r i ment i ng  with  decision  tables 
[18].  They  produced  a  table  different  in  form  but  identical 
in  concept.  The  emnhasis  was  placed  strictly  on  the  use  of 
decision  tables  as  an  aid  to  systems  documentation?  leaving 
the  solution  of  the  table  to  the  programmer. 

A  number  of  companies?  including  Hunt  Foods?  North 
American  Aviation?  and  the  Insurance  Company  of  North  Amer- 
ica? initiated  research  on  decision  tables  (111?  primarily 
to  facilitate  in-house  file-maintenance  and  system  documen- 
tation. 
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From  1960,  the  CODASYL  systems  study  group  has  car- 
pied  out  work  on  the  development  of  a  high-level  language* 
COBOL.  Decision  tables  were  selected  as  an  addition  to 
COBOL  and  in  1962,  the  specifications  of  DETAB-X  were  pub- 
lished. The  manual  described  a  decision  table  preprocessor 
that  could  accept  the  decision  tables  as  input  and  produce  a 
form  of  COBOL  codina  as  output.  This  was  the  first  table 
processor  available  to  computer  users. 

2.   Evolution  and  Refinement 

In  June  1965,  the  Soecial  Interest  Group  for  Pro- 
gramming Languages  (  S  I G  P  L  A  N  )  of  the  Los  Angeles  Chapter  of 
the  Association  of  Computing  Machinery  appointed  a  working 
group  to  develop  a  decision  table  preprocessor.  The  result 
was  the  distribution  of  DETAB/b5,  written  in  a  restricted 
subset  of  COBOL.  Although  implemented  on  the  CDC  3600  and 
IBM  709a,  among  others,  its  inefficient  conversion  algorithm 
1 ed  to  its  demi  se . 

It  has  become  evident  that  DETAB/65  was,  however, 
the  ancestor  of  the  current  group  of  proprietary  decision 
table  preprocessors  developed  since  1966.  General ly,  the 
processors  follow  the  DETAB/65  lead  in  that  they  are  a 
preprocessor  written  in  COBOL  that  converts  decision  tables 
containing  COBOL  components  to  a  stream  of  COBOL  source  code 
suitable  for  compilation.  There  are  several  exceptions  to 
this  basic  rule. 
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IBM's  System/360  Decision  Logic  Translator  processes 
decision  tables  coded  in  Fortran.  There  are  also  other  not- 
able examples  using  BASIC  and  ALGOL  (15] .  Some 
preprocessors  offer  the  programmer  the  option  of  specifying 
the  language  to  be  processed. 

3.   Use  Today 

A  review  of  decision  loaic  table  preprocessor  his- 
tory almost  forces  one  to  wonder  why  decision  logic  tables 
are  not  universally  used  for  systems  analysis*  program 
development f  and  documentation.  Many  times*  this  technique 
has  succeeded  where  the  more  widely  used  methods  of  narra- 
tive and  flowcharting  have  failed.  why  then  has  the  use  of 
decision  logic  tables  not  been  more  widespread? 

Three  possible  causes  have  been  identified.  First* 
the  amount  of  information  available  to  systems  analysts  and 
programmers  on  a  daily  basis  has  been  limited.  Although 
many  articles  have  been  published  o^jer  the  years*  they  have 
generally  aoDeared  in  hiqhly  technical  form  or  have  appeared 
in  proceedings  or  journals  not  extensively  circulated  to  the 
commercial  practitioner.  As  a  rule*  decision  tables  have 
not  been  tauaht  in  their  rightful  place  as  an  alternative  to 
flowcharts  in  introductory  programming  courses. 

Second*  the  use  of  decision  tables  requires  a  dif- 
ferent  apDroach   to  croblem  solving  than  does  flowcharting. 
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Flowcharting  leads  one  to  adopt  a  sequential  model  of  deci- 
sion making.  That  is,  a  test  followed  by  one  or  more 
actions.  On  the  other  hand;  decision  logic  tables  require 
an  overall  analysis  of  the  conditions  that  comprise  a  given 
problem  and  the  effect  of  their  various  combinations  on  the 
solution.  Natural ly,  there  is  much  resistance  among  those 
trained  in  sequential  type  analysis  to  accept  a  new  tech- 
n  i  que . 

Third,  there  has  been  a  general  lack  of  decision 
table  processors  available  to  the  data  processing  community. 
As  a  result,  tables  had  to  be  hand  translated  to  sequential 
code  for  input  to  the  computer.  Absence  of  a  mechanized 
means  of  translation  has  resulted  in  a  rapid  decrease  of 
interest  in  decision  tables  by  programmers. 

These  three  conditions  are  slowly  being  eased  with 
the  increase  of  books  and  articles  published  on  the  subject. 
Seminars  are  available  from  several  sources  and  presumably, 
the  historical  resistance  to  decision  tables  will  be  over- 
come . 

C.   FLOWCHARTING  VERSUS  DECISION  TABLES 

As  has  been  pointed  out;  narratives  and  flowcharting 
have  historically  loeen  used  to  document  computer  programs 
and  structure  their  logic.  These  techniques  have  been 
demonstrated   to   be   very  effective  time  and  time  again,  as 
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long  as  the  problem  remained  relatively  simple  and  straight- 
forward. However,  this  effectiveness  has  severely 
deteriorated  when  the  problem  became  more  complex. 

Decision  logic  tables  have  been  shown  to  provide  a  for- 
mat for  organizing  and  displaying  program  logic/  and  have 
been  compared  with  narratives  and  flowcharts  in  program 
documentation  and  logic  structuring.  This  comparison  has 
shown  a  number  of  important  advantages  and  disadvantages  of 
the  use  of  decision  logic  tables. 

One  advantage  of  decision  logic  tables  over  other  forms 
is  the  conciseness  normally  associated  with  a  decision 
table.  A  much  larger  amount  of  information  may  be  placed  in 
a  given  space  using  a  table  as  opposed  to  narratives  or 
flowcharts.  This  dense  display  of  information  provides  a 
much  clearer  reoresentat ion  of  the  program  logic  than  a 
cloudy  narrative  or  a  branching*  meanoering  flowchart. 

The  conciseness  of  decision  logic  tables  leads  directly 
to  their  second  advantage.  Namely*  the  advantage  of 
thoroughness  or  completeness.  The  person  preparing  decision 
logic  tables  is  forced  by  their  format  to  consider  all  pos- 
sible combinations  of  events.  This  is  guite  different  from 
the  flowcharting  approach  which  tends  to  emphasize  seauen- 
tial  logic  flow.  This  emphasis  on  sequential  logic  flow 
often  tends  to  obscure  alternative  logic*  and  may  thoroughly 
avoid  the   issue   of   loaic   completeness.    Failing   to   be 
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prepared  for  all   possible   combinations   of   events   is   of 
course  a  major  source  of  subtle  program  "bugs". 

Non-sequential  logic  flow  also  tends  to  assist  the  pro- 
grammer in  eliminating  other  logic  errors.  The  elimination 
is  due  to  the  manner  the  entire  flow  of  logic  is  displayed 
at  a  glance  in  the  case  of  decision  logic  tables.  The  pro- 
grammer is  thus  permitted  to  visualize  better  the  interrela- 
tionships and  alternatives  within  the  problem  at  hand.  Not 
only  is  completeness  displayed  but  also  redundant  tests  are 
pinpointed  thus  permitting  the  production  of  more  efficient 
code. 

Decision  logic  table  construction  and  modification  is 
easy  to  learn.  Thus*  a  non-orogramme r  can  normally  read  the 
logic  of  a  well  written  program.  Further,  deoendency  upon 
the  original  programmer  is  greatly  reduced  since  modifica- 
tions are    easy  to  perform. 

A  final  important  advantage  of  decision  logic  tables 
over  flowcharting  is  their  ability  to  serve  as  computer 
input.  This  permits  machine  checking  for  certain  tyoes  of 
logic  errors  and  mechanized  conversion  into  a  Drogram  seg- 
ment . 

Several  disadvantages  to  the  user  of  decision  logic 
tables  do  exist.  Perhaps  the  most  insidious  is  that  the 
sequential  flow  of  flowcharting  has  been  the  only   technique 
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taught  programmers.   The  effort  to  learn  something  "new"  has 
only  been  reluctantly  taken  in  may  cases. 

Another  drawback  is  that  although  it  is  easy  to  learn  to 

use   decision   logic   tables*   extensive  work  is  reguired  to 

become  truly  efficient  in  programming  with  them*  as   opposed 

to   programming   with   flowcharts.   When  using  a  computer  to 

convert  the   logic*   further   work   is   reguired  to   become 
familiar  with  the  translator  or  preprocessor. 

Even  though  the  flow  of  logic  is  improved;  the  actions 
specified  cannot  be  machine  checked  to  ensure  they  are 
correct*  or  even  feasible  for  that  matter.  Also*  the 
machine  is  incapable  of  recognizing  impossible  combinations 
of  events.  This  forces  the  programmer  to  perform  these 
checks  or  supply  some  escaoe  set  of  actions. 

The   advantages   and   disadvantages   of   decision  logic 

tables  discussed  here  have  been  summarized  in  Table  1.  They 

may  be  compared  with  those   of   flowcharts   that   have  been 
listed  in  Tab  1 e  2 . 

Clearly,  decision  logic  tables  are  not  a  panacea  for  all 
the  ills  of  data  processing  today.  However*  they  can  be 
used  as  a  very  effective  tool  to  ensure  proper  program  logic 
flow  and  should  be  used  in  conjunction  with  narratives  and 
flowcharts*  as  aporopriate. 
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ADVANTAGES: 

1.  Clear  enumeration  of  all  operations  performed. 

2.  Clear  identification  of  the  seauence  of  operations. 

3.  Easily  1  earned. 

4  •   Effective  means  of  communication  between  people  in  and 
out  of  data  processino. 

5.  Concise  and  compact  form  of  documentation. 

6.  Easy  to  construct*  modify  and  read. 

7.  Easy  visualization  of  re  1  a t i onsh i ds  and  alternatives. 

8.  Directly  adaptable  to  computer  operations. 

DISADVANTAGES: 

1.  May  be  larqe  for  complex  situations. 

2.  Multiple  tables  may  be  needed. 

3.  Graphic  display  of  flowcharts  may  be  more  meaningful. 

4.  Requirements  too  detailed  for  man-to-man  communication, 


TABLE  1.   Advantages  and  Disadvantages  of  Decision  Tables 
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ADVANTAGES: 

1  .   Eas  i  1 y  produced. 
2. .   Eas  i  1  y  1  earned. 

3 .   Can  describe  data  handling  and  computer  operations 
'4.   Can  be  oroduced  by  computer  algorithms  from  source 
programs . 

DISADVANTAGES: 

1.  Heavily  influenced  by  personal  preference. 

2.  May  be  difficult  to  follow  in  complex  Droblem. 

3.  Revision  is  difficult. 

4.  Limited  in  displaying  all  logical  elements. 

5.  Detailed  logic  flowcharts  are    unwieldy. 


TABLE  2.   Advantages  and  Disadvantages  of  Flowcharts 
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II.   DECISION  TABLE  STRUCTURE 


This  section  is  intended  to  introduce  decision  logic 
tables  by  describing  their  structure  and  the  rules  qoverning 
their  use.  Simply  stated,  a  decision  logic  table  is  a 
tabular  representation  of  all  elements  of  a  problem  from 
conception  to  solution.  Information  displayed  in  this 
manner  is  easily  comprehended  even  when  the  table  of  infor- 
mation represents  a  complex  logical  problem.  The  logic  used 
in  decision  tables  is  similar  to  that  which  is  used  every 
day*  with  or  without  the  aid  of    the  computer. 

A.   THE  ELEMENTS  OF  A  TABLE 

Before  describing  in  detail  the  table  itself,  several 
definitions  must  be  made  clear.  First*  a  decision  rule  is  a 
statement  that  prescribes  the  set  of  conditions  that  must  be 
satisfied  in  order  that  a  series  of  actions  be  taken.  For 
example,  the  following  is  a  decision  rule: 

If  a  laborer  works  more  than  40  hours  in  a  week, 
he  must  be  paid  his  regular  salary  rate  plus  the 
product  of  his  overtime  hours  times  his  hours  in 
excess  of  40  . 
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The  decision  logic  table  is  used  to  describe  the  possible 
decision  rules  derived  above.  That  is*  whether  or  not  the 
laborer  worked  more  than  4  0  hours  in  a  given  week. 

The  decision  table  itself  is  a  structure  for  describing 
a  set  of  related  rules.  Although  other  formats  of  decision 
tables  exists  some  of  which  are  easier  to  use  [18],  they  are 
all  oerrnutations  of  the  basic  format  shown  in  Figure  2. 


CONDITION 
STUB 


ACTION 
STUB 


CONDITION 
ENTRY 


ACTION 
ENTRY 


FIGURE  2.  Decision  Table  Structure 

As  illustrated,  the  table  is  divided  into  four 
guadrants.  The  uooer  left  Quadrant,  called  the  condition 
stub,  contains  all  the  conditions  oeing  considered  for  a 
particular  decision  rule.  The  condition  entry,  in  the  uDper 
right  guadrant,  combines  with  the  condition  stub  to  form  the 
condition  that  is  to  be  tested. 
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In  the  lower  left  quadrant*  is  the  action  stub.  It  con- 
tains a  simple  statement  of  the  actions  resulting  from  from 
the  conditions  listed  above  the  horizontal  line.  Action 
entries  are  disolayed  in  the  lower  right  quadrant.  In  this 
quadrant*  the  apDropriate  action  resulting  from  the  various 
combinations  of  responses  to  the  conditions  will  be  indi- 
cated. 

As  shown  in  Figure  3  *  the  table  also  contains  a  section 
called  a  table  header.  Actually/  this  identifying  data  is 
reguired  in  order  to  distinquish  it  from  all  other  tables  in 
a  gi  ven  j  ob  . 

TABLE  HEADER     RULE   HEADER 


R1 

R2 

R3 

R4 

CI 

C2 

C3 

Al 

A2 

A3 

■ 

FIGURE  3.  Basic  Elements  of  a  Decision  Table 
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The  information  that  might  be  found  in  a  table  header 
includes  a  table  number,  a  table  name,  the  table  type,  the 
number  of  rules,  conditions  and  actions,  and  any  other 
options  locally  established  to  simplify  translation. 

The  various  combinations  of  responses  to  conditions 
shown  in  the  condition  entry  quadrant  are  called  rules  or 
paths.  Each  is  qiven  a  number  for  identification  purposes 
in  the  rule  header  Dortion  of  the  table. 

B.   TABLE  ENTRIES 

If  a  condition  in  the  condition  stub  is  true,  a  Y  is 
entered  for  that  particular  rule  in  the  condition  entry. 
Conversely,  if  the  condition  is  false,  an  N  would  be 
entered.  Ahere  irrelevant  situations  occur,  a  "don't-care" 
is  indicated  by  a  dash  (-). 

Additionally,  two  other  entries  have  been  proposed  to 
indicate  mutual  exclusion  of  one  condition  with  another 
[18,8].  If  the  case  arises  within  a  single  rule  that  the 
satisfaction  of  some  test,  indicated  by  a  Y  or  N  entry, 
makes  some  other  entry  a  foreqone  conclusion,  then  the 
special  entries  '*'  or  ' $ '  may  be  used  to  indicate  this 
fact.  The  symbol  '*'  is  used  in  place  of  an  N  entry  under 
these  circumstances,  while  the  ' $ '  is  used  in  place  of  a  Y 
entry. 
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The  network  algorithms  and  several  sophisticated  algo- 
rithms that  attemot  to  minimize  execution  time  of  the 
translated  table  and/or  provide  completeness  checking  make 
excellent  use  of  these  implied  truth  values.  Those  algo- 
rithms provide  completeness  checking  which  accounts  for  the 
logically  imoossible  rules  introduced  by  condition  depen- 
dency . 

In  the  action  entry  quadrant*  an  X  is  entered  to  indi- 
cate that  action  which  is  to  be  executed  for  a  particular 
rule.  Any  given  action  may  be  executed  for  any  number  of 
rules*  however  a  rule  may  require  more  than  one  action  and 
where  an  X  is  entered  for  each  action  in  the  action  entry 
quadrant  . 

C.   TYPES  OF  TABLES 

There  are  three  types  of  decision  tables  in  current  use. 
The  limited  entry  table  is  the  most  popular  and  most  often 
used  [8],  Since  the  other  two  table  types*  extended  entry 
and  mixed  entry*  may  always  be  transformed  into  limited 
entry  tables*  the  preorocessor  develoDed  here  allows  only 
limited  entry  table  input.  The  other  two  types  of  tables 
will  be  discussed*  however. 

1.   Limited  Entry  Tables 

The  rules  reoarding  the  placement  of  information   in 
each   of   the   four   cuadrants   of  a  limited  entry  table  are 
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fixed  and  inflexible.   The  condition  and  its  state   must  be 

restricted   to   the  condition  stub.   The  condition  entry  may 

only  show  the  response  Y  (true)/  N  (false)/  *  (implicit  N) , 
$  (implicit  Y)  or  •-'  (don't  care). 

Likewise/  specific  actions  must  be  fully  identified 
within  the  action  stub  and  permissible  notations  within  the 
action  entry  sections  are  limited  to  an  'X'  or  a  blank. 

Table  3  shows  a  limited  entry  table  in  proper  for- 
mat. Note  that  entries  prescribed  for  one  quadrant  may  not 
extend  into  another  and  that  every  condition  entry  contains 
one  and  only  one  of  the  allowed  symbols.  Normally/  limited 
entry  tables  are  the  best  suited  to  computer  applications 
[13]  . 


LOAN  TABLE 

Rl 

R2 

R3 

R4 

SATISFACTORY 
CREDIT   LIMIT 

Y 

Y 

N 

N 

FAVORABLE 
PAY   EXPERIENCE 

Y 

N 

Y 

N 

APPROVE  LOAN 

X 

X 

REJECT  LOAN 

X 

X 

TABLE  3.  Limited  Entry  Table 
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2.       Extended  Entry  Tables 

In  extended  entry  tables*  the  variables  to  be  tested 
are  identified  in  the  condition  stub,  while  the  condition 
entry  must  define  the  value  or  state  of  the  variable.  Like- 
wise* in  this  type  of  table*  the  action  stub  names  an  action 
while  the  action  entrv  will  qive  the  specifics  for  the 
ac  t  i  on  named . 

As  shown  in  table  3,  the  format   is   not   quite   as 

strict   for   this  type  of  table.  The  use  of  this  format  may 

also  tend  to  decrease  the  number  of  items  in  both  the  condi- 
tion and  action  stubs. 


LOAN  TABLE 

Rl 

R2 

R3 

R4 

CREDIT 
LIMIT 

OK 

OK 

TOO 
LOW 

TOO 
LOW 

PAY 
EXPERIENCE 

OK 

POOR 

OK 

POOR 

LOAN 

APPROVE 

REJECT 

APPROVE 

REJECT 

TABLE  4.   Extended  Entry  Table 
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3.   Mixed  Entry  Tables 

i 

The  mixed  entry  table  is  a  combination  of  the  lim- 
ited entry  form  and  the  extended  entry  form.  Even  though 
these  two  forms  may  be  combined/  one  form  must  be  used 
exclusively  within  each  horizontal  row  of  a  table.  Table  5 
depicts  the  information  from  the  previously  used  tables  as  a 
mixed  entry  table. 


LOAN  TABLE 

m 

R2 

R3 

R4 

CREDIT   LIMIT 

OK 

OK 

TOO 

LOW 

TOO 
LOW 

FAVORABLE 
PAY  EXPERIENCE 

Y 

N 

Y 

N 

APPROVE  LOAN 

X 

X 

REJECT    LOAN 

X 

X 

TABLE  5.   Mixed  Entry  Table 
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III.   DECISION  TABLE  THEORY 


The  uses  for  decision  tables  vary  qreatly  throughout 
the  fields  of  business*  science*  and  engineering.  Whatever 
their  purpose*  a  sound  theoretical  basis  is  needed  to 
explore  further  the  intricacies  of  their  potential*  This 
section  is  dedicated  to  fulfilling  that  need  with  a  general 
overview  of  the  background  theory  of  decision  logic  tables 
and  specific  treatment  of  rule  mask  theories.  This  discus- 
sion is  a  orelude  to  the  tooics  of  table  completeness  and 
decision  rule  contradiction  and  redundancy. 

A.   GENERAL 

As  previously  stated*  a  decision  table  is  made  up  of  a 
set  of  conditions*  each  of  which  may  be  evaluated  as  true  or 
false  at  any  given  time.  The  truth  or  falsity  of  these  con- 
aitions  may  be  combined  in  various  ways*  along  with  a  series 
of  actions*  to  form  a  decision  rule. 

The  series  of  actions  contained  in  a  particular  decision 
rule  are  executed  when  a  transaction  is  evaluated  that 
matches  the  particular  combination  of  truth  or  falsity  of 
the  conditions  indicated  by  the  particular  rule. 
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The  decision  tables  presented  here  are  based  on  one  of 
the  Boolean  algebra  functions  known  as  the  AND  function.  It 
is  considered  to  be  the  ordered  set  of  Y's;  N's#  or  dashes 
that  appear  as  the  condition  entries  for  a  particular  deci- 
sion rule.  The  aoDlication  of  the  OR  function  can  also  be 
made  in  decision  tables  and  it  is  described  in  some  detail 
by  Pol  lack,  et  al .  [IB]  . 

In  order  to  illustrate  the  AND  function,  the  following 
table  is  presented  with  its  associated  AND  functions. 


Rl 

R2 

R3 

R4 

TYPE>60WPM 

Y 

Y 

Y 

N 

SH0RTHAND>90 

Y 

Y 

N 

— 

SALARY  5  $5500 

Y 

N 

— 

— 

HIRE 

X 

DO  NOT  HIRE 

X 

X 

REFER    TO 
TYPING  POOL 

X 

AND  function  1  =  Y,Y,Y 

AND  function  2  =  Y,Y,N 

ANO  function  3  =  Y,N,- 

AND  function  4  =  N,-,- 

FIGURE  4.  AND  Function  Examples 
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Basically*  to  determine  whether  or  not  a  decision  rule 
is  satisfied,  evaluate  the  AND  function  for  that  rule*  and 
check  that  it  eauals  the  reauired  transaction.  For  example? 
the  AND  function  of  rule  3  would  be  satisfied  if  the  job 
applicant  could  type  60  op  more  words  per  minute  but  could 
not  take  dictation  at  a  speed  greater  than  90  words  per 
minute.  For  this  rule*  condition  3*  the  possible  salary*  is 
of  no  conseauence  to  the  ultimate  satisfaction  of  the  rule. 

B.   CONDITIONS 

So  far*  the  word  condition  has  been  used  numerous  times 
without  a  complete  definition.  A  condition  is  a  variable 
factor  affecting  the  actionfs)  to  be  taken  in  a  given  situa- 
tion by  its  presence*  absence*  or  chanqe  in  value.  Series 
of  conditions  with  their  associated  rule  entries  make  up*  in 
part*  decision  loaic  tables.  The  symbol  n  will  be  used  to 
represent  the  number  of  conditions*  each   denoted   by   "C  "* 


1 


"C  "*  etc.*  oresent  in  the  table. 
2 


tohen  a  table  is  evaluated*  the  various  conditions  are 
found  to  be  either  true  or  false.  This  truth  value  is 
stored  in  a  matrix  M  according  to  the  following  code  pro- 
posed by  Press(20], 


M     =  1  and  M     =0  implies  the  condition  is  true 
if  1  i  *2 

M     =  0  and  M     =  1  implies  the  condition  is  false 
if  1  i  ,2 
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Therefore*  for  N  conditions  the  following  matrix  M  would 
be  formed: 


M 


1.1     1,2 

I       M 
2,1     2,? 

I        M 

5,1     3,2 


M       M 
n  ,  1     n  ,  2 


Each  vector  of  the  matrix  thus  formed  is  called  a  mask. 

1  •   Structure  of  Conditions 

Each  condition  is  most  often  made  ud  of  two  operands 
related  by  a  relational  ooerator.  For  incut  to  the  oreoro- 
cessor  developed  here,  the  conditions  must  each  be  grammati- 
cally correct  C  languaae  expressions.  For  instance,  in  its 
most  basic  form,  one  operand  in  a  condition  statement  must 
be  a  variable,  while  the  other  may  be  a  constant  or  vari- 
able. The  relational  operators  may  be  any  one  of  the  fol- 
lowing C  1 anauaae  operators: 

=  =   <r   >=    <   >    1  = 


For  example,  consider  the  following  three  conditions 
in  which  a  variable  is  compared  to  an    integer: 
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x  <  10 


y  >=  15 


z  !=  0 


At  the  time  of  evaluation/  the  truth  value  is  determined  for 

each  C  .   Given  that  x  =  5/  y  =  20,  and  z  =  0,  the  following 

i 
matrix  containing  two  masks  would  be  obtained: 


1 

0 

1 

c 

0 

1 

Condition  statements  may  also  be  made  up  of 
subroutine  calls  or  variables  or  even  any  combination  of 
these  separated  by  logical  operators.  They  must/  however, 
evaluate  as  loaically  true  or  false, 

2.   Condition  Dependency 

Between  any  two  pairs  of  conditions,  there  exists 
either  dependence  or  independence.  Basically,  two  condi- 
tions are  dependent  if  they  both  have  the  same  condition 
variable  as  an  operand.  Conversely/  two  conditions  are 
independent  if  there  is  no  common  condition  variable  used  as 
an  operand. 
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There  are  two  types  of  dependence.   First*  there   is 

mutual   exclusion  dependency.   This  case  occurs  when  for  any 

pair  of  conditions  C   and  C  ,  there  is  no  value  of  the   com- 

i        J 
mon  condition  variable  such  that  their  mask  entries  are  both 

equal  "1,0",  true.   However,  this  is  not  to   say   that   both 

conditions  may  not  be  false  at  the  same  time. 

By  extention  to  more  than  two  conditions*  it  may  be 
said  that  any  number  of  conditions  are  mutually  exclusive  if 
at  any  point  in  time  every  two  conditions  in  each  of  the 
pairs  of  conditions  are  mutually  exclusive. 

The  second  tyoe  of  dependency  is  termed  overlapping 
dependency.  Overlapping  deoendency  occurs  when  there  can 
exist  at  least  one  value  of  a  conoition  variable  common  to  a 
pair  of  conditions  such  that  both  conditions  are  true. 
Other  combinations  of  truth  and  falsity  may  also  occur. 
Condition  dependency  thus  dictates  that  certain  combinations 
of  condition  values  are  impossible  events.  These  impossible 
events  represent  impossible  rules  and  need  not  be  considered 
by  the  proarammer  when  describina  the  program  logic.  How- 
ever, machine  checking  for  condition  dependency  is  seldom 
implemented  in  translation  algorithms.  This  causes  the 
machine  to  interpret  the  decision  logic  table  as  being 
i  ncompl et  e . 
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3.   Condition  Entry  Notation 


The  condition  entry  portion  of  a  decision  table  con- 
tains one  of  the  following  entries  for  a  condition  C  /  which 

i 
have  the  meaning  given: 


•Y'  =>  C   is  required  to  be  true, 
i 

• N '  =>  C   is  required  to  be  false, 
i 

'-'  =>  C   is  immaterial, 
i 

**'  =>  C   is  false/  if  some  other  explicit 
i 


condition  is  proven. 


'$'  =>  C   is  true/  if  some  other  explicit 
i 


condition  is  Droven. 


In  the  arguments  to  follow/  the  dash  or  '-'  will   be 

denoted   by   I    for   a  condition  C  ,  where  the  condition  is 

i  i 

immaterial  and  C   neeo  not  be  proven  either  true   or   false. 

i 
Also/  it  should  be  oointed  out  that 


I   =  Y   +  N 
i      i      i 


where  +  is  an  inclusive  OR 

Analogously/  the  symbols  '*'  and  '$'   indicate   that 
the   condition   they   represent   need  not  be  proven  false  or 
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true.   They  implicitly  represent  both  Y   and  N   for  a  condi 

i       i 
tion  C   and  thus  have  the  full  Dower  of  both*  if  tested, 
i 


C.   AND  FUNCTIONS 


In  the  discussion  to  follow*  an  AND  function*   B  *   will 

i 
be  considered  to  be  defined  as: 


B   =  W     &  W     &  W     4 
j     1  t  J     2  *  j     3  *  j 


&  W 


n*  j 


Where  W   is  a  vector  representing  any  one   of   the   possible 

i 
condition   entries   for   condition   i  and  '&'  is  the  Boolean 

operator  AND. 


Each  independent  condition  may  reouire  W   to  be  Y  *   N  * 

i  i     i 

or   I  .    Dependent   conditions   may   take   on   the  implicit 

i 
requirements  *   and  $    *  but  these  are  special   cases   of   Y 

i       i  i 

ana   N  *  respectively.   Therefore  a   may  be  expressed  in  one 

i  i 

of  three  states:   Y  ,  N   or  I  .   Thus*  the  number  of   oossi- 

i    i       in 
ble  forms  of  an  AND  function  is  3  . 


Recall  that  the  matrix  M  represents  the  truth  or  falsity 
of   n   conditions.    Given   a  particular  matrix  M *  it  may  be 

determined  for  V  whether  V(B  )*  the   logical   value   of   B  * 

i  i 

equals   1   or  0  by  first  makina  appropriate  entries  for  each 

w     of  B  *  according  to  the  rules  indicated   in   Figure   5. 

i  t  j      j 
For  example*  suppose 


B   =  (Y  Y  N  *  I  Y) 

j 

and 
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M  = 


1 

0 

0 

1 

0 

1 

1 

0 

0 

1 

1 

0 

Then,  according  to  the  replacements  indicated  in   Figure 
5/  we  have 

B   =(101111) 

J 


Therefore^  V(B  )  =  0.   Had  the  resulting   B    contained   all 

J  J 

1 ' s »  the  logical  value/  V  ( B  )  ,    would  have  been  1  . 

J 


w 
k#  j 

VCC     ) 
k 

Y 

0     1 

Y 

1     0 

iM 

0     I 

N 

1    0 

* 

0    1 

* 

1     0 

S 

0     1 

S 

1    0 

I 

0     1 

I 

1    0 

ReD lace  with 


FIGURE  5.   Table  of  Peo  1  acement s  for  Determining  V(B  ) 

J 
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As  an  example^  consider  aqain  the  following  conditions: 


C  :  x  <  10     C  :  y  >=  15     C  :  z  1=  0 
1  2  3 


Given  that  x  =  5/  y  =  20 f     and  z    -    0,       the   following   matrix 
was  obtained: 


mm 

~ 

1 

0 

1 

0 

0 

1 

_ 

n 

From  a  typical  decision  table  that  may  be  easily  formed,  the 

following  AND  function  is  oresent: 

6   =  (Y  Y  Y) 
1 

Again,  according  to  the  replacements  indicated  in  Fiqure 

5 ,    we  obtain 


R   =(110) 

1 


And  V  ( B  )  =  0.   The  first  AND  function  tested  is  not   satis- 

1 
fied  and  its  associated  action(s)  will  not  be  done.   Another 

function  must  be  considered. 


1.   Dependency  of  AND  Functions 


Dependency  amono  AND  functions  is  somewhat  different 

than   that   among  conditions.   Two  AND  functions/  B   and  B  / 

i       J 
are  dependent  if  for  at  least   one   set   of   values   of   the 

conditions   variables   and   reou i rement s /  both  V ( B  )  =  1  and 

i 
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V(B  )  =  1.   Otherwise?  the  AMD  functions  are  independent  and 

J 

no  one  set  of  the  condition  variables  set  V(B  )  and  V ( B  )  to 

i         i 
1. 


For  example?  consider  the  following   two   AND   func- 
t  i  ons  : 


B   =  Y  ,  Y  ,  Y  ,  N 


B   =  Y  ,  Y  ,     Y  ,    N 

a 


Then  for  a  set  of  values  of   the   condition   variables   that 
yields 


M  = 


1 

0 

1 

0 

1 

0 

0 

1 

both  V(B  )  =  1  and  V(B  )  =  1.   Thus?  B   and   B    are   depen- 

3  a  3       a 

dent.    Had   either   V(B  )   =  0  or  V(B  )  =  0,  then  B   and  B 

3  a  3      a 

would  have  been  founo  to  be  independent. 


2 .   Definitions 

A  oure  AND  function  is   one   that   contains   no   "I" 
entry.   For  example/ 

P  =  Y  ,  *     r     % 
is  a  pure  AND  function. 
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A  decision  rule  is  simple  if  it  contains  a  Dure  AND 
function.  A  mixed  AND  function  is  one  that  contains  one  or 
more  I's.  A  decision  rule  is  complex  (or  compound)  if  it 
contains  a  mixed  AND  function. 

D.   THEOREMS  FOR  AMD  FUNCTIONS 

In  the  theorems  that  follow*  a  table?  T,  is  assumed  to 
comprise  all  AND  functions  that  can  generate  fro^  the  condi- 
tions of  that  table.  The  theorems  are  presented  for  infor- 
mational purposes  only.  Detailed  proofs  are  presented  by 
Pol  lack  [18]  . 

THEOREM  I.  Within  table  T,  two  AND  functions  are 
independent  if/  in  at  least  one  position,  one  func- 
tion contains  a  Y  and  the  other  function  contains  a 
N .   Otherwise/  they  are  dependent. 

For  an  illustration  of  theorem  I,  consider  the  following 
i  ncomo l e t  e  table. 


CI 


C2 


C3 


AFl 


Y 


AF2 


N 


AF3 


Y 


Y 


N 


Ar 


~\ 


A/ ' 


AFl  and  AF2  are    cfppendent  since  there  does  not  exist   at 
least  one  Y t N  oair  for  the  three  conditions. 


3R 


AF2  and  AF3  are  independent  because  a   Y*N   oai  r   exists 

for  cond  i  t  i  on  C  . 

2 


THEOREM  II.   Within  table  T,  each  pure  AND   function 
is  independent  of  every  other  pure  AND  function. 

Consider  the  following   table   for   an   illustration   of 
t  heorem  II. 


AF1 

AF2 

AF3 

AF4 

CI 

Y 

Y 

N 

N 

C2 

Y 

N 

Y 

N 

By  definition,  all  four  AMD  functions  are  pure.  From 
theorem  I*  they  are  independent.  In  this  example,  there  are 
no  other  pure  AND  functions  possible  and  therefore  each  pure 
AND  function  is  independent  of  every  other  pure  AND  func- 
tion. 

THEOREM  III.   Within  table  T,  every  mixed  AND   func- 
tion  that   contains  I  in   positions  ( 1  <=  r  <  n)  is 

r 
dependent  on  each  of  2       oure  AND  functions  of  T. 


Consider  the  followinq  partial  table. 


CT_ 
C2 
C3 


AF1 
Y 

N 


AF2 
Y 

Y 
Y 


Ar 
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A  F  1  exoands  to  contain  the  following  pure  AND  functions. 


AFla 


AFlb 


Referrinq  to  theorem  I ,     AF1  is   dependent   on   AFla   and 
AFlb. 


THEOREM  IV.   Table  T,  based  on   n   conditions,   con- 

n 
tains   one,  and  only  one/  set  of  2       independent  pure 


f unc t  i  ons . 


As  an  illustration  of  theorem  I  V  >  consider  the  followina 


tabl e. 


AFT 

AF2 

AF3 

AF4 

AF5 

AF6 

AF7 

AF8 

CI 

Y 

Y 

Y 

Y 

N 

N 

N 

N 

C2 

Y 

Y 

N 

N 

Y 

Y 

N 

N 

C3 

Y 

N 

.Y 

N 

Y 

N 

Y 

N 

i*J  i  t  h  the  total  number  of   conditions   eaual   to   3,   the 

3 
total  number  of  pure  AMD  functions  should  be  2       =  8>  accord- 
ing to  theorem  IV.   As  can  be  seen  above*  no  other  pure   AND 
function   exists  that  does  not  duplicate  one  of  those  in  the 
tabl e. 
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THEOREM  V  .   Any  decision  rule  that  contains  I   in   r 

positions   (0   <=   r   <   n)   of   its  AND  function  is 

r 
equivalent  to  2       simple  decision  rules. 


Theorem  V  is  illustrated  by  the  following  Dartially  com- 


plete   t  ab 1 e  . 


Rl 


CI 


C2 


Al 


A2 


Y 


X 


R2 


N 


N 


X 


Ar 
Ar 


Ar- 

Ar~ 
Ar~ 


1 


The  co^olex  decision  rule*  Rl »  is  ecuivalent  to  2  =  2 
simple  decision  rules/  Rla  and  Rib,  both  of  which  contain 
pure  decision  rules. 


Rla 

Rib 

Y 

Y 

Y 

N 

X 

X 
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IV.   PREPARING  DECISION  TABLES 


A.   BASIC  TECHNIQUES 

This  section  Dresents  two  methods  for  the  development  of 
decision  tables.  The  classical  techniaue  and  the  progres- 
sive rule  development  techniaue*  both  of  which  follow  the 
formal  preoaration  rules  presented  in  an  earlier  section. 

In  the  classical  techniaue*  all  possible  combinations  of 
conditions  are  considered  and  a  matrix  is  produced  in  the 
condition  entry  which  reoresents  all  possible  simple  rules. 
Next;  the  table  is  simolified  by  repeatedly  combining 
several  simple  rules  into  a  comolex  rule*  thereby  producing 
fewer  rules.  The  process  becomes  almost  mechanical*  how- 
ever* and  it  is  oossible  to  lose  sight  of  the  total  problem 
1 ogi  c  . 

The  other  method*  by  progressive  rule  development*  is 
based  on  formalized  rules  adapted  from  flowcharting.  The 
logic  of  the  problem  is  considered  step  by  step  and  the 
table  prepared  as  the  problem  is  studied.  Normally*  this 
method  is  somewhat  fasten  than  the  classical  one.  Because 
the  development  of  the  table  is  in  step  with  the  loaical 
analysis  of  the  problem*  the  total  logic  can  always  be  seen. 
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It  should  be  pointed  out  here  that  the  form  of  the  deci- 
sion table  should  reflect  its  ultimate  use.  When  preparing 
a  decision  table  for  preprocessing,  compact/  sophisticated 
logic  should  be  reflected  in  the  table.  A  1 t ernat i ve 1 y ,  if  a 
table  is  to  be  used  purely  for  documentation  purposes/  it 
would  be  best  for  the  table  to  be  laid  out  in  a  simple/ 
easily  readable  form.  The  fact  that  over  soph i st i cat i on  in 
compressing  logic  and  in  minimizing  the  number  of  rules  pro- 
duces a  table  which  is  more  difficult  for  the  ultimate  user 
to  understand  should  be  kept  in  mind.  Furthermore/  if  care 
is  not  used/  errors  may  inadvertantly  be  introduced. 

B.   CLASSICAL  TECHNIQUE 

The  classical  technique  emphasizes  the  development  of  a 
matrix  represent  inn  all  the  simple  rules  for  the  given  con- 
ditions. Then  the  full  matrix  will  be  reduced/  if  possible/ 
to  a  fewer  number  of  rules  by  combining  the  simple  rules  to 
form  complex  rules.  The  following  seven  steos  may  De  fol- 
lowed almost  mechanically  to  produce  a  logically  correct  and 
relatively  concise  table. 

1.  List  all  conditions 

2.  List  all  actions 

3.  Complete  condition  entry  (for  full  matrix) 
*l .  Complete  action  entry 
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5.  Consolidate  and  form  complex  rules 

6 .  Chec  k  table 

7.  Transcribe  final  version  and  recheck 

This  technique  can  be  used  for  all  three  types  of  tables 
(limited/  extended/  and  mixed  entry).  Each  of  the  seven 
steps  will  be  described  in  the  following  sub-sections. 

1  •   List  Conditions 

By  thorough  study  of  the  problem  under  considera- 
tion, all  the  relevant  conditions  may  be  determined  and 
listed.  At  this  point/  the  statement  of  the  condition 
should  be  as  clear  and  concise  as  possible.  In  order  to 
avoid  logically  correct/  but  complicated  statements/  nega- 
tive expressions  should  be  avoided  whenever  possible.  A 
negative  statement  relies  on  a  double  negative  for  the  posi- 
tive case.  For  examole/  the  condition  "no  soace  available" 
gives  Y  (out  of  space)  and  N  (space  available). 

As  a  general  rule/  conditions  which  are  not  indepen- 
dent should  also  be  avoided.  Often,  where  one  condition 
includes  another/  there  may  be  some  misunderstanding  of  the 
problem  at  hand.  Conditions  which  are  not  independent  pro- 
duce impossible  rules  and  incomplete  loaic  tables. 

Logically/  the  sequence  of  the  conditions  tested 
does  not  affect  the  validity  of  the  table/  but  it  does 
affect  the  ease  of   reading   and   table   construction.    The 
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basic  guide  to  follow  is  to  list  conditions  in  order  of  most 
likely  satisfaction.  When  their  relative  likelihood  is  not 
known/  listing  in  the  sequence  in  which  identified  is  a  good 
starting  point.  It  is  imperative  to  list  all  possible  condi- 
tions before  proceeding  to  the  next  step. 

cL .   List  Ac  t  i  ons 

Listing  the  actions  next  allows  a  double  check  to 
ensure  that  all  the  conditions  have  been  listed.  Action 
statements  are  generally  easier  to  formulate  than  condition 
statements  and  are  generally  given  as  some  sort  of  command. 
For  convenience/  actions  should  ne  listed  in  the  seguence  in 
which  they  are  to  be  Performed.  This  rule  is  mandatory  when 
advanced  techniaues/  such  as  recursion  or  table  linkage/  are 
ut  i 1 i  zed  . 

3.   Complete  Condition  Entry 

At  this  step/  the  condition  entry  part  of  the   table 

is   filled   in.    The   object  here  is  to  state  all  the  rules 

which  represent   all   combinations   of   conditions   with   no 

repetition   or   omission   of  any  combination.   As  previously 

n 
stated/  for  a  limited  entry  table  there  are    2       simple  rules/ 

where  n  is  the  number  of  conditions. 

At  the  conclusion  of  this  step/  a  completed  matrix 
is  formed  in  the  condition  entry  oortion  of  the  table  con- 
sisting of  all  the  possible   simple   rules.    If   the   above 
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procedure  is  followed*  each  rule   will   be   unique   and   all 
rules  will  contain  every  combination  of  conditions. 

4.  Complete  Action  Entry 

At  this  ooint/  each  rule  is  examined.  The  condition 
entry  is  considered  and  the  appropriate  actions  indicated. 
Any  action  required  must  be  consistent  with  any  other  action 
required.  In  the  event  contradictions  among  actions  can  be 
identified  at  this  ooint*  they  must  be  resolved  by  specify- 
ing an  appropriate  error  action.  Above  all*  it  is  vital  to 
be  consistent  in  handlino  any  ambiguous  combination  of  con- 
ditions. 

5 .  Consolidation 

In  conso 1 i da t i nq  a  limited  entry  table*  consider  two 
rules  with  identical  actions  at  a  time.  For  each  pair*  the 
two  rules  may  be  consolidated  if  all  the  condition  values 
are  the  same  exceot  one  oair.  For  the  condition  with  the 
unmatched  Dair*  a  dash  is  entered.  This  one  complex  rule 
then  replaces  the  two  simple  rules.  Continuinq  in  this 
manner  will  result  in  a  smaller*  more  manaqeable  table. 

6.  Check  Taole 

At  each  of  the  stages  oreviously  described*  the  work 
done  on  the  table  should  be  checked.  The  earlier  an  error 
is  detected*  the  easier  it  is  to  rectify.   The   checks   that 
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should  be  applied  fall  into  two  broad  categories:    checking 
for  content  and  checking  for  structure. 

Checking  the  content  should  ensure  that  the  action 
entries  associated  with  each  simple  rule  on  the  unconsoli- 
dated table  are  correct.  Checking  the  structure  of  the 
final  table  is  an  attempt  to  ensure  that  the  table  contains 
no  contradictions  or  redundancies. 

7.   Make  Final  Version 

Once  a  table  has  been  checked,  it  may  be  necessary 
to  transcribe  it  to  produce  a  final  version  which  can  then 
be  used.  The  condition  and  action  stubs  should  be  checked 
to  make  sure  that  they  are    clear. 

Normally,  the  conditions  are  listed  so  that  those 
with  the  most  "don't  care"  entries  are  at  the  bottom  of  the 
list.  Similarly,  the  seauence  of  rules  can  be  altered  so 
that  those  rules  containinq  the  most  "don't  care"  entries 
appear  first.  Large  tables  may  be  divided  into  smaller  por- 
tions for  checking. 

C.   PROGRESSIVE  RULE  DEVELOPMENT  TFCHNIQUE 


Progressive  rule  develocment  is  based  on  standard  tech- 
niques for  preparinq  flowcharts.  Whereas  the  classical 
technique  requires  that  all  possible  combinations  of  condi- 
tions be  defined,  progressive  rule  development  reguires  that 
conditions  be  written  on  the  table  as  they  are       identified. 
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Each  rule*  including  the  action  entry,   is   entered   as   the 
problem  is  analyzed. 

The  procedure  for  progressive  rule  development  as  pro- 
posed by  London  fill  is  enumerated  below.  Note  that  the 
steps  are  reoeated  until  the  comolete  table  has  been  formed. 

When  all  possible  conditions  have  been  considered,  the 
table  should  be  checked  for  contradictions  and  redundancies. 
The  following  sub-sections  point  out  the  major  points  to  be 
kept  in  minrt  at  every  step. 

1.  Consider  a  Condition 

At  this  point,  a  condition  should  be  clearly  entered 
into  the  condition  stub.  As  a  starting  point,  enter  a  Y 
(true)  response  in  the  condition  entry  adjacent  to  the  con- 
dition. 

2.  Consider  Further  Conditions 

Determine  what  other  conditions  are  necessary  before 
action  can  be  taken.  Thev  must  also  be  entered  in  the  table 
as  in  step  1.  The  action  portion  of  the  table  may  then  be 
completed  for  this  newly  formed  rule. 

3.  Form  Next  Rule 

The  next  rule  may  be  formed  by  transcribing  the  pre- 
vious rule,  changing  the  last  condition  entry  for  which  all 
values  have  not  been  considered.   For  example,   the   last   Y 
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value  entered  should  be  chanqed  to  an  N.   All   values   above 
the  changed  value  are  kept  the  same. 

D.   AN  EXAMPLE 

This  section  presents  a  solution  to  the  following  sample 
problem  using  the  classical  technique. 

Hiring  a  Receptionist 

A  new  receDtionist  is  needed  for  an  insurance 
company.  She  must  be  able  to  type  at  least  60 
words  per  minute  and  take  dictation  at  a  minimum 
of  90  words  per  minute.  All  applicants  should 
be  willing  to  work  for  a  salary  not  greater  than 
$5500  a  year.  All  applicants  who  meet  typing 
reguirements  but  not  the  dictation  reauirements 
will  be  referred  to  the  tyDing  pool. 


The  first  step  is  to  identify  the  conditions  that  must 
be  met.  They  are  then  placed  in  the  condition  stub  of  the 
decision  Ionic  table  in  some  order  of  precedence  (see  Table 
6).  All  oossible  actions  should  be  placed  in  the  action 
stub  next. 
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Rl 

1    ■        '    ' 

R2 

R3 

R4 

R5 

R6 

R7 

R8 

TYPE  ^  60  WPM 

Y 

Y 

Y 

Y 

N 

N 

N 

N 

SALARY«S  #5500 

Y 

Y 

N 

N 

Y 

Y 

N 

N 

SHORTHAND*  90 

Y 

N 

Y 

N 

Y 

N 

Y 

N 

HIRE 

X 

DO   NOT   HIRE 

X 

X 

X 

X 

X 

REFER  TO 
TYPING  POOL 

X 

X 

TABLE  o.   Hiring  a  Reception  ist 

The  number  of  rules  reaui  red  to   consider   all   Dossible 
combinations  of  conditions  is: 


Number  of  rules  =  2 

where  n  =  the  number  of  conditions 
In  this  case*  ft  rules  are  required*  as  indicated  in  Table  6. 
Note*  however,  that  rules  5  thru  ft  may  be  combined  due  to 
the  fact  that  failing  the  tvoing  condition  results  in  the 
action  "Do  Not  Hire"  in  all  cases.  Thus/  it  can  be  seen 
that  the  table  may  be  dramatically  simplified  immediately. 

Further,  the  table  may  be  reduced  to  the  one  deoicted  in 
Table  7  by  notinq  the  fact  that  upon  satisfying  condition  1 
but  failure  of  condition  2 ,  an  ability  to  take  shorthand  at 
a   rate   of   90   or   more   words  per  minute*  results  in  that 
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applicant  being  refered  to  the  typing  pool.  Note  that  rear- 
ranging conditions  in  order  of  least  number  of  don't  care 
entries  results  in  the  final*  bifurcated  form  shown.  That 
isr  it  is  arranged  whereby  each  condition  has  its  Y  answers 
grouped  together  and  its  N  answers  grouped  together  to  form 
pat  hs . 


Rl 

R2 

R3 

R4 

TYPE  >  60  WPM 

Y 

Y 

Y 

N 

SH0RTHAND>90 

Y 

Y 

N 

— 

SALARY^  $5500 

Y 

N 

— 

— Z— 

HIRE 

X 

DO  NOT  HIRE 

X 

X 

REFER    TO 
TYPING  POOL 

X 

TABLE  6.   Hiring  a  Receptionist  -  Final  Solution 
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V.   PREPROCESSOR  DESCRIPTION 


A.   THE  ALGORITHM 

There  were  a  multitude  of  different*  sometimes  opposing/ 
attributes  that  the  desired  a  1  a  o  r  i  t  h  m  was  to  possess.  These 
ranged  from  the  traditional  considerations  of  output  module 
size  and  execution  soeed  to  restrictions  arising  from  the 
intended  implementation  computer  facility. 

The  choice  of  compiler,  interpreter,  or  preprocessor  was 
resolved  in  favor  of  the  preprocessor  due  to  the  considera- 
tions dictated  by  the  general -Purpose,  mult  i -user,  interac- 
tive operating  system  UNIX  [7],  as  implemented  at  the  Naval 
Postgraduate  School,  and  its  support  of  the  programming 
language  C  [23].  Precarina  either  a  compiler  or  interpreter 
would  have  entailed  duplication  of  that  support  to  some 
degree . 

Algorithms  have  been  developed  to  attempt  to  minimize 
execution  time,  execution  module  size,  or  both  (19],  The 
minimization  effort  arose  from  the  consideration  that  the 
prepared  execution  module  was  to  be  used  repeatedly,  with 
the  preprocessor  itself  being  used  relatively  infrequently 
on  individual  tables.  However,  in  the  academic  situation, 
the  emphasis  has  been  placed  on  preparing  a  working  module 
rather   than   preparing   a   production   type   module.    This 
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indicates  that  the  preprocessor  itself  will  be  used  rather 
frequently  and  the  output  module  will  be  used  very  seldom. 
This  led  to  the  realization  that  the  preprocessor  size  and 
execution  time  were  of  areater  importance  than  output  module 
size  and  execution  time.  It  was  therefore  considered  desir- 
able for  the  preprocessor  code  to  be  small  in  size  and  quick 
in  execution.  Further,  the  data  area  of  individual  users 
was  to  be  relatively  small  yet  still  capable  of  handling 
more  than  ten  to  twelve  conditions  in  the  decision  logic 
tabl e. 

The  final  attribute  of  major  importance  was  that  the 
algorithm  be  capable  of  beina  implemented  with  a  minimum  of 
user  skill.  It  was  felt  that  several  sophisticated  algo- 
rithms 1 1 8 # 22 f 28 , 21]  ,  while  of  major  importance  in  both  the 
academic  and  industrial  communities,  demanded  too  much  user 
input  to  be  desirable  for  beginning  decision  logic  transla- 
tor users . 

The  various  network  algorithms  described  [  1  8 , \ 9 , 28  ,  1 0] 
were  eliminated  as  a  class  since  the  data  area  available  in 
our  m i n i -comout er  was  insufficient  for  ten  to  twelve  condi- 
tions and  the  preprocessor  execution  time  was  estimated  to 
be  excess  i  ve . 

Rule  mask  algorithms  have  been  shown  to  be  highly  effi- 
cient with  respect  to  storage  reauirements  (execution  module 
size)  [19],  translator  size,  and  execution  time,  but  poor 
with   respect   to   execution   module   run   time   since   each 


sa 


condition  had  to  be  tested  to  prepare  the  mask  and  then  this 
mask  compared  with  all  the  rule  masks.  This  objection  faded 
when  it  was  recognized  that  the  target  user  group  would/  in 
general/  be  but  slightly  concerned  with  performing  the  sta- 
tistical background  work  necessary  to  provide  the  input  data 
to  obtain  truly  optimal  execution  time  code. 

The  rule  mask  techniaue  of  Press  [201  has  been  shown  to 
be  very  good  with  rescect  to  execution  module  run  time  [193. 
Additionally/  the  target  user  grouo  was  expected  to  be  capa- 
ble of  Drogrammina  decision  logic  tables  using  the  input 
reguired  by  this  algorithm  with  relative  ease. 

For  these  reasons/  the  choice  of  an  algorithm  was  that 
of  Press  [20],  This  aloorithm  built  a  rule  mask  for  each 
rule.  Code  was  generated  to  seauentially  evaluate  each  con- 
dition and  construct  a  test  mask  from  the  results.  The  rule 
masks  were  then  scanned  to  find  one  that  matched  this  test 
mask. 

This  algorithm,  on  one  hand/  did  not  require  a  large 
data  area/  which  would  have  been  the  case  with  a  network 
algorithm.  Yet/  on  the  other  hand/  the  programmer  was  given 
nothing  to  control  execution  time  of  the  output  program 
other  than  simply  placing  the  rules  in  decreasing  order  of 
expected  frequency  of  satisfaction. 

In  order  to  provide  a  smaller  preprocessor  module  to 
document   the   grammar   of   the  decision  logic  table/  and  to 
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simplify  any  future  changes  to  that  grammar/  Y  A  C  C  /  a 
compiler-compiler  developed  by  Bell  Laboratories  16] ,  was 
used  in  the  construction  of  DELTRANS/  the  decision  logic 
translator  proposed  here. 

B.   GENERAL  OPERATION 

As  previously  stated/  DELTRANS  was  designed  to  be  a 
seguential  testing  rule  mask  decision  logic  table  transla- 
tor. This  meant  that  for  each  decision  logic  table  DELTRANS 
was  to  prepare  a  rule  mask  to  match  each  rule*  generate  code 
to  test  each  condition  sequentially  and  set  a  test  mask/  and 
finally  generate  code  to  test  the  test  mask  against  the  rule 
masks/  searching  for  a  match. 

To  accomplish  the  enumerated  tasks  DELTRANS  was  con- 
ceived to  ODerate  in  five  distinct  but  interdependent 
phases.  The  five  phases  were  designated  c  o  d  y  /  data  area 
initialization/  data  input/  computation/  and  finally  code 
generation.  When  more  than  one  table  was  to  be  preprocessed / 
DELTRANS  returned  to  the  copy  phase. 

As  designed/  DELTRANS  began  execution  in  the  copy 
phase.  Code  was  merely  transferred  from  the  input  to  the 
output  file/  removing  comments  while  searching  for  the 
first  uo  arrow  (t)  not  within  auoteS/  which  indicated  the 
start  of  a  decision  logic  table. 
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At  this  point  DELTRANS  entered  the  data  area  initializa- 
tion phase.  In  this  phase/  DELTRANS  read  a  list  of  user 
options  such  as  the  number  of  actions  (or  conditions*  and 
initialized  the  internal  structures  in  preparation  for  table 
input.  The  user  was  provided  with  a  great  deal  of  flexibil- 
ity in  both  size  and  format/  and  considerable  error  checking 
was  performed  during  this  phase. 

If  all  initialization  inout  was  in  order/  the  preproces- 
sor proceeded  to  the  third  chase/  data  input.  In  this 
phase/  the  table  was  read  and  its  contents  sorted  and  stored 
for  the  next  phases.  Once  again/  extensive  error  checking 
was  done  during  this  phase. 

ifllhen  the  final  un  arrow  in  a  table  was  read  and  the  data 
input  phase  complete/  DELTRAMS  shifted  into  the  computation 
phase.  In  this  phase  there  were  two  major  events/  ambiguity 
and  completeness  checkinq  and  the  construction  cf  the  indi- 
v  i  dua 1  rule  masks. 

The  final  phase  of  code  generation  was  the  point  of  gen- 
eration of  both  the  output  code  and  a  formatted  decision 
logic  table  for  use  in  debugging.  DELTRANS  returned  to  the 
copy  phase  to  pass  on  any  additional  code  or  prepare  for  a 
following  table. 

All  but  the  final  phase  of  the  preprocessing  could  cause 
fatal  errors.  If  an  unexpected  end-of-file  was  encountered/ 
an  error   message   resulted   and   the   output   buffers   were 
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flushed  into   the   output   file.  Otherwise*   the  standard 

recovery  technique  was  to  search  for  the  up  arrow,  which  was 

assumed  to  mark  the  end   of   the  current   table*  and   then 
restart  from  the  cooy  phase. 

C.   AMBIGUITY  AND  COMPLETENESS  CHECKING 

DELTHANS  was  designed  to  perform  two  distinct  types  of 
table  logic  checking  for  the  user/  but  had  no  capability  of 
correcting  any  errors  exposed  during  this  logic  checking. 
Completeness  checkino  was  attempted  only  after  the  ambiguity 
checking  was  completed  and  no  errors  found. 

Ambiquitv  checkino*  as  performed  by  DELTRANS*  was  based 
on  two  fundamental  requirements  for  all  decision  logic 
tables  [191.  First*  every  rule  must  have  at  least  one  asso- 
ciated action.  And  second*  each  distinct  combination  of 
truth  values  for  the  given  set  of  conditions  must  satisfy 
exac  t  1  y  one  rule. 

The  first  requirement  arises  because  for  every  set  of 
conditions  some  action  is*  in  fact*  intended  or  should  be. 
Whether  that  action  be  return  to  the  calling  point  in  the 
program,  halt  prooram  execution  immediately*  or  enter  an 
infinite  no-operation  loop*  some  program  action  is  intended. 

Checking  for  redundancy  and  inconsistency  in  table  con- 
struction has  been  implemented  by  comparing  the  rules  to 
insure  that  between  each  pair  of  rules  there  exists  at  least 
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one  condition  row  with  opposing  logic  entries  for  the  two 
rules.  If  no  opposing  loaic  entries  are  founds  their  ident- 
ical actions  indicate  a  redundant  table  and  differing 
actions  indicate  an  inconsistent  table. 

Examples  of  both  cases  can  be  readily  observed  in  table 
8.  Rules  Rl  and  R2  are  redundant  while  R3  and  R4  are  incon- 
sistent. Note  that  the  implicit  entries  are  considered  to 
be  equivalent  to  the  explicit  entries  and  therefore  there  is 
a  lack  of  opposing  logic  entries. 


Rl 

R2 

R3 

R4 

CI 

Y 

8 

N 

N 

C2 

S 

— 

N 

X 

C3                   | 

— 

N 

— 

Y 

Al                    | 

X 

X 

X 

A2                  J 

X 

TABLE  8.  Redunaancy  and  Inconsistency  Example 

Only  if  the  input  decision  loaic  table  was  non-ambiguous 
did  DELTRAfgS  attempt  to  determine  if  that  table  was  com- 
plete. Comoleteness  testing  on  an  ambiguous  table  is 
unnecessary.  As  previously  noted/  Pollack/  Hicks*  and 
Harrison  [181  have  proven  that   each   decision   logic   table 
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contains  2       independent  simple  rules/  where  n  is  the   number 

of   conditions.    They   have   also   proven   that   all   rules 

n 
represent  2       simple  rules/  where  n  is  the  number   of   "don't 

cares"   in   that   rule.   DELTRANS  has  incorporated  these  two 

theorems  in  its  completeness  testing. 

If  a  decision  logic  table  contains  two  or  more  dependent 
rules  it  is  said  to  be  ambiguous.  In  that  case  the  two 
theorems  on  comoleteness  would  not  apply.  Therefore  the 
ambiguity  checking  was  designed  to  preceed  the  completeness 
checking. 

W hen  checking  for  completeness?  the  preprocessor  was 
designed  to  scan  each  rule  for  a  count  of  the  "don't"  care" 
entries  in  that  rule.  For  each  rule*  2  was  raised  to  the 
power  of  this  count  and  the  resulting  value  added  to  a  tally 
sum  for  the  entire  table.  ^hen  all  rules  had  been  scanned* 
this  fally  was  compared  with  the  value  of  2  raised  to  the 
number  of  conditions.  If  these  two  were  equal  the  table  was 
complete?  otherwise  the  table  was  incomplete. 

If  an  input  decision  logic  table  was  found  to  be  com- 
pleter the  else/error  rule  can  never  be  satisfied  and  is 
therefore  superfluous.  Since*  bv  design*  DELTRANS  requi  red 
an  else/error  action*  it  was  necessary  to  provide  the  pro- 
grammer with  the  capability  to  input  a  null  action  (not  a 
no-ooer a t i on )  to  be  used  with  complete  tables. 
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If  the  count  of  simple  rules  in  a  decision  logic  table 
revealed  that  not  all  possible  rules  had  been  enumerated; 
the  else/error  action  was  examined.  If  that  action  was  a 
null  action,  then  DELTRANS  was  designed  to  output  a  warning 
message  indicating  that  an  incomolete  table  had  been  encoun- 
tered. Of  course*  if  the  orogram  had  specified  a  valid 
else/error  action  then  the  decision  logic  table  is#  by 
def aul t  r  comnl et e . 
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VI.   CONCLUSIONS  AND  RECOMMENDATIONS 


A.   CONCLUSIONS 

Throughout  the  available  literature*  decision  logic 
table  structure  and  terminoloqy  was  found  to  be  rather 
straightforward  and  s t anda rd i zed #  as  presentee  here.  This 
has  facilitated  the  programmer's  use  and  understanding  of 
decision  Ionic  tables. 

The  theory  upon  which  decision  logic  table  construction 
and  translation  has  been  based  was  found  to  vary  between 
extremes.  Pollack  and-  others  118]  have  presented  clear  and 
direct  foundations  for  construction  and  translation.  Some 
alaorithms  were  discovered  which  were  based  more  on  intui- 
tion than  theory  [ 2 8 ]  r  while  others  were  founded  in  theory 
so  complex  that  programmers  have  had  difficulty  in  grasping 
the  looic  of  a  given  problem  [4,22*24]. 

The  advantages  that  decision  logic  tables  offer  have 
shown  that  every  programmer  should  at  least  be  introduced  to 
decision  logic  tables  and  thus  be  able  to  use  this  powerful 
t  oo  1  . 

Decision  loaic  tables  can  oe  a  powerful  aid  in  effective 
communicating*  both  man-to-man  and  man-to-machine*  in  pro- 
gramming* and  in  documentina.   The  format  of  decision   logic 
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tables  permits  organization  and  concise  visual  presentation 
of  complex  logic.  Decision  logic  tables  also  provide  the 
programmer  with  a  very  effective  tool  for  insuring  that  the 
program  logic  is  both  correct  and  complete*  items  that  other 
methods  tend  to  obscure. 

Additionally/  since  decision  logic  tables  are  both  easy 
to  construct  and  modify/  and  may  be  used  as  computer  input/ 
decision  Iodic  tables/  when  properly  used/  can  be  an 
extremely  effective  tool  for  communicating/  programming/  and 
document  i  ng . 

Of  the  many  decision  logic  table  translators  avail- 
a  b 1 e  [  1 4 1  /  DELTRAMS/  as  oroDosed  here/  was  the  only  known 
available  translator  desioned  for  implementation  on  the  UNIX 
timesharing  system  for  the  C  programming  language. 

The  ultimate  value  of  DELTRANS  lies  in  its  versatility 
of  application  throughout  management/  scientific/  and 
engineering  fields.  Decision  logic  tables  themselves  pro- 
vide a  simple  method  for  recording  logic  so  that  all  ele- 
ments of  a  decision  are  precisely  defined.  Tables  make  it 
possible  for  managers/  scientists/  and  engineers  to  use  com- 
puters directly.  Nuch  subsequent  programming  and  coding  may 
be  eliminated. 

DELTRANS/  as  developed/  fills  that  gap  between  a  C  pro- 
grammer with  decision  tables  and  the  C  language  compiler. 
The  Naval  Postgraduate  School  has  been  provided  with  a   tool 
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for  use  in  introducing  students  to  the  use  of  decision  logic 
tables.   A  tool  that  until  now  has  not  been  available. 

8.   RECOMMENDATIONS 

Several  refinements  to  DELTRANS  have  been  suggested  to 
further  enhance  its  utility.  Prior  to  enumerating  the  most 
important  of  these  refinements  it  should  be  pointed  out  that 
each  of  these  reguirements  conflicts  with  some  of  the  design 
criteria  used  in  constructing  DELTRANS. 

Additional  completeness  testing  and  error  checking  capa- 
bilities would  assist  the  orogrammer  with  complex  logic.  If 
the  necessary  space  and  time  were  deemed  appropriate/  the 
preprocessor  could  be  so  modified  to  take  full  advantage  of 
the  implicit  entries  during  completeness  checking.  Further 
cooing  could  provide  for  automatic  error  correction  of  a 
number  of  programming  errors*  for  examole  combining  redun- 
dant rules. 

An  alternate  conversion  algorithm  could  be  implemented. 
By  using  one  of  the  network  algorithms  that  has  been  proven 
to  provide  minimum  execution  time  output/  the  capabilities 
of  DELTRANS  would  be  enhanced.  Since  the  data  structures 
for  holding  the  actions/  conditions/  and  rules  and  for  link- 
ing the  rules  to  the  actions  were  built  and  maintained  by 
DELTRANS/  the  implementation  of  an  additional  coding  algo- 
rithm  would  be  simplified.   However/  these  algorithms  would 
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require  additional  programmer  input  and  additional  time   and 
space  for  the  preprocessor. 

If  deemed  appropriate/  the  required  increase  in  size  and 
decrease  in  speed  in  the  preprocessor  could  be  accepted  and 
DELTRANS  could  be  modified  to  accent  extended  and/or  mixed 
entry  cond  i  t  i  ons . 

A  conversational  translator  could  be  developed  using 
DELTRANS  as  a  base.  This  would  qreatly  reduce  the  file 
manipulating  reauired  of  the  oroarammer  under  DELTRANS. 

A  final  recommendation  is  that  decision  logic  tables  be 
presented  to  students  as  a  part  of  an  introductory  computer 
science  course.  Even  if  tables  must  be  hand  translated/ 
decision   logic   tables   can  provide  areat  assistance  to  the 

proorammer/  whether  he  be  a  beginner  or  experienced. 
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APPENDIX  A  -  DELTRANS  USER'S  MANUAL 


Effective  Use  of  DELTRANS 

DELTRANS  is  designed  to  be  utilized  by  those  fluent  in 
the  design  and  construction  of  decision  logic  tables.  Those 
without  such  a  background  are  directed  to  the  appropriate 
sections  of  the  parent  thesis  itself  and  Solomon  Pollack's 
work  Dec  i s  i  on  Tables:  Theory  and  Practice  [181  for  an  intro- 
duction to  decision  loaic  tables. 

Additionally*  some  basic  familiarity  with  the  UNIX 
operating  system  is  assumed;  spec i f i c a  1 1 y /  using  the  edi- 
tor»  programming  in  C,  and  file  manipulation.  The  paper 
"UNIX  for  Beginners"  by  Kernighan  [71  is  an  excellent  start- 
i  nq  point. 

Only  with  a  thorouqh  qrasp  of  the  concepts  of  both 
decision  tables  and  UNIX  may  a  user  of  DELTRANS  reap  its 
intended  benefits  as  described  herein. 
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I.   INTRODUCTION 


Decision  loqic  tables  describe  decision  rules.  A  deci- 
sion rule  consists  of  a  set  of  conditions  plus  a  set  of 
actions.  The  relationship  between  conditions  and  actions  is 
of  the  IF-THEN  tyoe.  More  specifically,  if  the  given  condi- 
tions are  met,  then  the  corresponding  actions  are  taken. 

DELTRANS  allows  C  programmers  to  convert  a  C  program 
containing  one  or  more  decision  logic  tables  into  a  C  source 
program  ready  for  comoilation. 

The  user  needs  only  a  basic  knowledoe  of  the  C  language 
in  order  to  use  DELTRANS.  The  decision  table  input,  nested 
within  a  C  program,  must  conform  to  the  specifications  of  a 
C-oriented  decision  table  language  presented  in  section  II 
of  this  manual.  The  1 anquage  described  combines  decision 
table  capabilities  with  many  of  the  features  of  C. 

DELTRANS  processes  one  decision  table  at  a  time.  It 
reads,  decodes,  and  edits  each  line  of  the  table.  Messages 
are  printed  on  the  terminal  when  errors  are  detected.  The 
decision  table  is  outout  as  C  source  code  on  a  specified 
file.   Optionally,  a  formatted  listing  may  be  obtained. 
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The  decision  logic  translator  is  designed  for  use  on 
the  PDP-11  with  the  UNIX  operating  system  and  64K  bytes  of 
user  program  storage. 

A.  PURPOSE 

The  purpose  of  DELTRANS  is  to  provide  an  alternative  to 
the  C  programmer  when  faced  with  a  complex  logical  situa- 
tion. The  preorocessor  is  designed  to  be  convenient  for 
preparing  C  programs  containing  decision  logic  tables  at  a 
remote  terminal.  A  cecision  looic  table  may  be  included 
within  any  C  program,  along  with  any  syntactically  correct  C 
expressions. 

B.  FUNCTIONS  PERFORMED 

Briefly*  DELTRANS  ooens  and  reads  from  the  input  file 
specified  by  the  user  and  oreprocesses  the  C  orogram  con- 
tained therein.  The  oefault  is  input  from  the  terminal 
itself.  Source  code  is  placed  on  the  output  file  also 
specified  by  the  user.  Its  default  name  is  'd.tab.c'.  This 
file  is  initially  opened  and  then  closed,  along  with  the 
input  file,  when  Drep rocess i ng  is  complete.  Each  decision 
logic  table  is  coded  as  a  seoarate  subroutine  in  this  file. 

Optionally,  a  formatted  and  thus  very  readable  copy  of 
each   decision   table   contained   in   the   incut  file  may  be 
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redirected  to  the  line  printer  or  any  other  file   upon   com- 
pletion of  preprocessing. 

Additionally^  the  decision  logic  table  is  examined  for 
ambiguous  or  incomplete  logic. 

C.   LIMITATIONS 

The  processor  limitations  described  here  are  due  to  the 
dimensions  of  various  arrays  internal  to  the  preprocessor. 
Most  of  these  limitations  may  be  relaxed  by  minor  altera- 
tions to  the  preorocesso r ;  a  consultant  may  be  of  some 
assistance  in  this  enaeavor. 

The  following  list  of  maximum  values  must  be  strictly 
adhered  to  avoid  processing  errors. 

Maximum  number  of  conditions  =  16 

Maximum  number  of  actions  =     32 


Maximum  number  of  rules  = 


6a 


Maximum  stub  length  = 


31  charac  t  ers 


Addi t i ona 1 1 y t     the  name  of  the  table  subroutine  may  be  no 
more  than  8  characters. 

The  oreorocessor  was  written  using  a  rule  mask   scanning 
technique.    A   fundamental   assumption   reauired  when  using 
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this  technique  is  that  every  condition  is  tested  when 
preparing  a  mask  which  is,  in  turn*  used  to  scan  for  the 
proper  rule.  This  fact  forces  the  programming  limitation 
that  each  condition  return  a  valid  test  regardless  of  the 
results  of  previous  tests.  Note  that  the  conditions  are 
tested  sequent i a  1 1 v f  first  to  last. 

Note  especially  the  reserved  words  dda»  ddb,  and  ddc. 
These  may  not  be  usea  in  the  logic  in  decision  logic  tables 
since  the  preprocessor  uses  these  as  names  for  the  masks. 

Finally*  the  up  arrow,  except  when  inside  quotes  (single 
or  double)  will  be  read  as  a  definite  signal  to  the 
preprocessor. . .beware! 

D.   ADDITIONAL  BACKGROUND 

The  preprocessor  was  written  during  January  ana  Febru- 
ary, 1977,  as  a  thesis  project  by  Lt .  J.F.  Keller  and  Capt . 
R.rt.  Roesch. 

Subroutines  required  by  the  system  are    as  follows: 

getc      putc      fopen      printf 

exit      fflush      fcreat 

The  YACC  library  routines  are    also  reguired. 
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II.   GENERAL  INFORMATION 


A.   ACCEPTABLE  INPUT 

A  decision  logic  table  may  occur  anywhere  within  a  C 
program;  however?  it  is  normally  considered  as  a  procedure 
and  should  be  treated  accordingly.  As  shown  in  Figure  \r 
the  table  itself  is  first  recognized  by  the  preprocessor  by 
the  occurrence  of  a  left  arrow  (•«-')  as  the  first  character 
of  any  line  within  a  C  program. 

The  table  itself  is  divided  into  three  distinct  sec- 
tion s  /  separated  by  the  ud  arrow  (  '  T  '  )  /  as  depicted  in  Fig- 
ure 1.  As  shown?  the  sections  are  identified  as  the  option 
section,  the  condition  section,  and  the  action  section. 


OPTION  SECTION 


CONDITION  SECTION 


ACTION  SECTION 


FIGURE  1.   Decision  Table  Format 
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1 
2 
3 

a 

5 
6 
7 
8 
9 
10 
11 
12 
13 
14 
15 
16 
17 
18 
19 
20 
21 
22 
23 
2a 
25 
26 
27 
28 
29 
30 
31 
32 
33 
3a 
35 
36 
37 


int     r[61  {    0,     1,-2,-3,    2,-3>; 

int    sf6]  <-a,    9,-7,     0,-4,-1}; 

int     t 16]  {-1 ,     3,-2,-1 ,     0,     3>; 

main  ( )  { 
int  k  ,* 
for  (k  =  0;  k<6;  k  +  +  )  { 

printf("\nThe  numbers  to  test  are  :\n"); 

printf("\tR  =  %d\n\tS  =  %d\n" , r C kl  , s  [  k]  ) ; 

printf("\tT  =  %d\n"  ,  t  [k]  )  ', 

logtab(k) ; 


rpos  (  )  { 

print f("R  is  pos i t i ve . \n" ) ; 


logtab  (c)     int  c  ,*   { 

//  this  is  a  comment 
5  c  3 

a 
s> 

int  a ; 

char  b ; 


c]<osy(i-3,a 

cl  <  0  3  y ( 1 ,2) 
c)     <    0  a  yC 1-4)  -(5) 
n(2-3)  ; 


)  N  ( 5 )  ; 

n  (  3  ,  4  )  ; 


t 

or 
pr 
or 
rp 

«- 


i  n  t  f  (  "  T  <  0  :  "  )  3  a  ,  \  ; 

i  n  t  f  (  "  S  <  0  :  "  )  a)  1,2; 

i  n  t  f ( " R  <  0  \ n  " )  9  1,2,3,4; 

o  s  (  )  <D  5  ; 


FIGURE  2.   Example  Program  with  a  Decision  Logic  Table 
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Each  section  has  a  specific  format  and  although  there  is 
much  freedom  of  input  allowed*  several  rules  must  be  fol- 
lowed as  described  in  the  following  sub-sections. 

1.   The  Ootion  Section 

The  format  of  the  option  section  is  relatively  freer 
however  several  items  must  appear  and  be  initialized.  Docu- 
menting comments  follow  the  rules  of  C  and  thus  may  appear 
anywhere  within  this  section.  In  accordance  with  those 
rules,  they  must  be  preceeded  by  a  double  slash  ('//')  or 
preceeoed  by  '/*'  and  followed  by  '*/'. 

The  possible  oDtions  are    listed  below. 


1.  'a'  or  'A' 

2.  »c'  or  'C 

3.  'd'  or  'D' 


number  of  actions  :  required 
number  of  conditions  :  reaui  red 
dec  1 arations 


U .     'e'  or  'E'  :  else  /  error  action 

5.  •  n '  or  ' N '  :  subroutine  name 

6.  'r'  or  'R'  :  number  of  rules 


opt  i  ona 1 -see 

be  1  ow 
regu  i  red 
requ  i  red 
reau i  red 


If  the  declaration  ootion  ('d'  or  'D')  is  used  in  a 
table*  it  must  be  the  last  ootion  used  in  the  option  section 
of  that  table.  All  variables  local  to  the  decision  table 
itself  must  be  declared  to  avoid  future  compilation  errors. 
As  shown  in  Figure  2 ,     the  declarations  must  oe  syntactically 
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correct  C  declarations.  DELTRANS  implements  this  feature  by 

passing  untouched   to  the  output  file  all  code  between  the 

'd'  (or  'D')  and  the  up  arrow  at  the  end  of  the  option  sec- 
tion. 

Additionally?  the  following  options  must  be  speci- 
fied in  the  format  indicated: 

a.  The  number  of  conditions: 

c  <number>   or   C  <number> 

b.  The  number  of  rules: 

r  <number>   or   R  <number> 

c.  The  number  of  actions: 

a  <number>   or   A  <number> 

Again,  as  shown  in  Figure  2,  these  options  may  be  specified 
in  free  form  with  one  or  more  soaces  between  a  letter  and  a 
numbe  r  . 

Another  reouired  option  is  the  name  or  '  n  '  option. 
It  must  also  aooear  before  the  declarations  and  must  be  of 
the  following  format: 

n  <name>  (<formal  oarameters>)  <type  spec i f i cat i ons>  ;  { 


where 
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1  n '  may  be  ' N ' , 

<name>  may  be  from  1  to  8  characters 

<formal  parameters>  is  optional  depending  upon 
required  carameters. 

<type  soec i f i c at i ons>  are  required  for  all  parame- 
ters dec  1  a  red . 

For  example*  line  <?  0  in  Figure  2  names  the  output 
subroutine  "logtab"  with  one  parameter*  "c".  Compare  with 
the  output  code  in  Fiqure  4. 

The  final  rea uired  entry  in  the  oDtion  section  is 
the  else/error  action.  The  preprocessor  will  physically 
code  this  as  the  final  "else"  action  is  the  output  code. 
The  format  of  the  else/error  is  an  'e'  (or  'E')  followed  by 
any  number  (including  zero)  of  blanks  and  tabs  followed  by  a 
strinq  of  at  most  31  characters  followed  by  '  o) '  .  The  31 
characters  must  form  a  valid  C  expression  or  group  of 
expressions. 

2.   The  Condition  Section 

The  condition  section  is  orqanized  as  a  series  of 
condition  lines  with  the  end  of  the  section  indicated  by  an 
up  arrow. 

Each  condition  line  contains  four  entries:  a  condi- 
tion  stub   of   up  to  31  characters;  an  at  sign  (  '  5) '  )  *  which 
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indicates  the  end  of  the  condition  stub;  an  optional  list  of 
truth  values  corresponding  to  numbered  rules;  and  finally  a 
semicolon,  which  indicates  the  end  of  the  condition  line. 

The  condition  stub  is  copied  character  for  character 
(maximum  31),  up  to  the  at  sign,  directly  into  the  appropri- 
ate internal  structure. 

The  format  for  the  list  of  truth  values  is  rela- 
tively free-form  in  that  tabs,  spaces,  and  newlines  are 
ignored  when  appropriate.  The  default  entry  for  each  rule 
is  a  "don't  care"  or  aash.  To  overwrite  with  any  logic 
letter  (Y,y,(\i,n, *,$,-),  that  logic  letter  is  Dlaced  in  front 
of  a  set  of  parentheses  containing  the  list  of  rules  for 
which  that  loaic  letter  is  to  be  entered. 

This  list  of  rule  numbers  must  contain  at  least  one 
rule  number  and  may  be  in  either  or  both  of  two  formats. 
The  first  format  is  a  list  of  single  rule  numbers,  separated 
by  commas,  in  any  cesired  order.  The  second  or  "through" 
format  uses  one  rule  number,  a  dash,  and  then  another  rule 
number.  The  effect  of  this  format  is  to  enter  the  selected 
logic  letter  into  each  rule  starting  with  the  first  and 
including  all  the  rules  through  the  last.  See  Figure  2 
lines  28-31  for  examoles  of  condition  lines. 

When  all  the  logic  letter  overlays  have  been 
entered,   a   semicolon  is  entered  to  alert  DELTRANS  that  the 
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end  of  the  truth  values  for  the  current  condition  has  been 
found  and  that  the  preprocessor  must  proceed  to  either 
accept  the  next  condition  stub*  or»  if  the  up  arrow  is  found 
nextr  proceed  to  decoae  the  action  section. 

DELTRANS  was  constructed  with  the  intention  that  it 
be  used  as  a  basis  for  additional  work  in  providing  decision 
logic  table  processing  caoability.  The  original  imDlementa- 
tion  does  not  use  the  implicit  entries  ('*'  and  *$')  in 
either  completeness  test inq  or  in  construction  of  the  output 
code.  The  programmer  is  nonetheless  strongly  encouraged  to 
use  these  entries  since  they  helo  to  brina  out  the  logic  of 
the  problem  at  hand. 

3.   The  Action  Section 

The  action  section  is  organized  as  a  series  of 
"action  lines"  with  the  end  of  the  section  indicated  by  a 
left  arrow.  The  left  arrow  is  used  since  the  end  of  the 
action  section  is  also  the  end  of  the  incut  for  the  current 
table. 

Each  action  line  contains  four  entries!  an  action 
stub  of  ud  to  31  characters?  an  at  sign  to  indicate  the  end 
of  the  action  stub?  a  list  of  rules  for  which  the  action  is 
to  be  performed?  and  a  semicolon  to  indicate  the  end  of  the 
action  line. 
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The  action  stub  is  copied  character  for  character 
(maximum  31)  ud  to  the  at  sian  directly  into  the  appropriate 
internal  structure. 

The  format  of  the  list  of  rules  is  relatively  free- 
form  in  that*  once  again,  tabs,  spaces,  and  new) ines  are 
ignored  when  approDriate.  The  default  entry  for  each  rule 
is  not  to  perform  the  current  action.  Thus,  to  indicate  the 
action  is  reauired  for  a  list  of  rules,  that  list  of  rules, 
separated  bv  commas,  is  entered.  No  particular  order  of 
rule  numbers  is  required.  See  Figure  2.  lines  33-37  for 
examples  of  action  lines. 

i/vhen  the  list  of  rules  has  been  entered,  a  semicolon 
is  input  to  alert  OELTRANS  that  the  end  of  the  current 
action  line  has  been  discovered  and  that  OELTRANS  must  per- 
form the  actions  reauired  to  determine  whether  or  not  to 
terminate  this  phase  of  operations. 

B.   PROGRAMMING  TECHNIQUES 

Although  any  beginning  programmer  familiar  with  C,  UNIX, 
and  decision  logic  tables  should  be  able  to  construct  a 
valid  incut  decision  logic  table  for  OELTRANS,  there  are 
three  specific  aspects  of  input  programming  that  a  more 
advanced  proarammer  should  know. 
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1  .   Rule  Sequence 
i 

One  process  by  which  a  programmer  may  increase  the 
average  execution  speed  of  the  output  execution  module  is  by 
proper  ordering  of  the  rules  in  the  decision  logic  table. 
After  testing  the  various  conditions  to  prepare  the  test 
mask,  that  test  mask  is  compared  with  each  rule  in  seguence. 
Thus*  if  the  programmer  will  code  the  input  decision  logic 
table  so  that  the  rules  will  bf»  listed  in  decreasing  fre- 
quency of  sat i s f ac t i on ,  the  average  execution  time  of  the 
output  execution  module  will  be  decreased. 

2.   ELSE  /  ERROR  Action 

The  else/error  rule  and  its  associated  action  should 
be  the  subject  of  considerable  thouoht  when  programming 
decision  logic  tables.  If  thev  are  improoerly  used  the  exe- 
cution speed  of  the  ouout  module  can  be  seriously  degraded. 
This  degradation  in  oerformance  results  from  the  output  code 
testing  the  test  masks  against  each  rule  mask  with  no  match 
until  the  final  else  is  found.  For  this  reason  it  is  recom- 
mended that  the  else/error  action  only  be  performed  for  very 
infrequent  transactions. 

In  the  event  that  a  proorammer  is  convinced  that  no 
else/error  action/rule  is  needed;  provisions  have  been  made 
for  a  null  else/error  action  entry.  To  input  a  null 
else/error  action,  the  first  non-blank  and  non-tab  character 
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after  the  'e'  or  'E'  in  the  option  section  should  be  the  at 
sign.  Note  that  a  null  action  is  not  a  no-operation.  In 
particular^  do  not  use  a  null  action  for  the  else/error 
option  if  a  return  is  really  intended.  A  null  action  for 
the  else/error  action  causes  the  last  input  rule  to  become 
the  default  action  in  order  to  avoid  the  last  test  of  bit 
masks  for  the  sake  of  speed. 


1 

2 
3 

a 

5 

6 

7 

8 

9 

10 

11 

12 

13 

14 

15 

16 

17 

18 

19 

20 

21 

22 


TABLE  SUMMARY  FOLLOWS 

TABLE  NUMBER      1. 
number  of  conditions 
number  of  rules 
number  of  actions 

CONDITIONS: 

rlc]  <  0 
s [cl  <  0 
t  (cl  <  0 

ACTIONS: 


RULES: 

o)  y  y  y  y  n 

a)  y  y  n  n  - 

a)  y  n  n  y  - 


d  r  i  n  t  f  (  "  T  <  0  :  "  ) 

d  r  i  n  t  f  (  "  S  <  0  :  "  ) 

printfC'R  <  0  \n  "  ) 

rpos ( ) 

****  NULL  ELSE/ERROR  ACTION  **** 

Table  1  is  complete  and  non-ambiguous. 


3  X      X 

(3  X  X 

a  x  x  x  x 
a        x 


FIGURE  3.   Example  of  Formatted  Output  from  DELTRANS 
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3.   Action  Seauence 

When  a  particular  rule  is  satisfied,  the  actions 
designated  for  that  rule  are  performed  in  the  order  listed. 
If  severe  programming  difficulties  should  arise  from  this 
restriction,  the  problem  may  be  eased  by  listing  an  action 
in  more  than  one  place  in  the  inout  decision  logic  table. 
This  will  not  affect  the  size  of  the  output  execution 
modu 1 e . 

C.   OUTPUT  GENERATED 

OELTRANS  not  onlv  generates  a  codeo.  execution  module  but 
also  generates  a  formatted  decision  logic  table  for  program- 
mer use  in  documentation  and  debugging. 

Figure  3  contains  the  formatted  output  from  the  example 
program  in  Figure  2.  This  formatted  output  is  written  into 
the  standard  outout.  (See  section  III  for  a  discussion  of 
input  and  outDut  files.)  In  Figure  3  the  table  number  is  on 
line  4 .  Lines  5  through  7  contain  a  summary  of  the  program- 
mer input  for  number  of  rules,  actions,  and  conditions. 
Lines  9  through  2\  display  the  four  auadrants  of  the  deci- 
sion logic  table.  Line  22  soecifies  the  else/error  action 
and  the  last  line  contains  the  ambiguity  and  completeness 
message.  Error  messaoes  are  also  directed  to  the  standard 
output.   See  section  I V  for   error   messages   and   suggested 
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correcting  actions.   Section  III  contains  procedures  for  the 
correction  of  errors. 

The  coded  execution  module  is  written  into  the  output 
file.  The  format  of  this  code,  while  difficult  to  under- 
stand at  first  glance*  can  assist  the  Drogrammer  in  debug- 
ging syntax  errors  in  input  decision  logic  tables.  Figure  4 
contains  the  code  generated  by  DELTRANS  from  the  input  pro- 
gram in  Figure  2  .  Line  2  0  in  Figure  ?  contains  the  name  and 
parameters  for  the  subroutine  which  appear  in  Figure  4  on 
line  19.  In  Figure  4 ,  line  23  contains  the  declarations  for 
the  rule  masks  (dda)/  and  the  test  mask(ddb  and  ddc ) .  Lines 
25  through  29  initialize  the  test  mask  and  rule  masks. 
Lines  30  through  35  provide  the  code  to  test  the  conditions 
and  set  the  test  mask.  The  remainder  of  the  code  searches 
for  a  match  between  a  SDecific  rule  mask  and  the  test  mask/ 
and  also  contains  the  actions  to  be  executed  if  a  match  is 
found. 

The  • n '  or  ' N '  option  placed  the  subroutine  name  in  the 
ouput.  The  'r'  and  'c'  options  determined  the  number  of 
tests  to  be  performed  and  the  number  of  rule  masks.  The  'a' 
option  merely  limits  the  number  of  actions  to  the  internal 
storage  requirements  in  DELTRANS.  The  final  else  is  used 
for  the  final  rule.  Note  that  the  actions  and  conditions 
appear  in  the  output  in  the  same  order  they  have  in  the 
i  nput  . 
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int  r(6J  {  0,  1,-2,-3,  2,-3}; 
int  sl61  {-4,  9,-7,  0,-4,-1}; 
int  t  [6)      {-1  ,  3,-2,-1  ,  0,  3}  ', 

main  ( )  { 

int  k ; 

for  (k=0;  k<6;  k++)  < 

pr i nt f ( °\nT he  numbers 
printf(M\tP  =  %d\n\tS 
print f  ("\tT  =  %d\n",t Ekl ); 
1 oatab(k) ; 


to  test  are  :\nM); 
=  %d\n", p tk] ,s Ck]  )  ; 


roos  (  )  {  , 

printf("R  is  Dositive.W); 


1  og 


tab(c) 
int  a ; 
char  b ; 


int  c ; 


l  nt 

ddb  = 
dda  I 
dda  ( 
dda  t 
dda  f 
dda  [ 
if(r 

i  f  (s 

i  f  (t 

i  f  (( 


e  1  se 

e  1  se 
e  1  se 

e  1  se 


dda  ( 
o; 

01  [0 
1]  [0 

2)  [0 

3)  [0 
4]  [0 
[cl 
ddb 

(cl 
ddb 
[c] 
ddb 
dda  f 
or  i  n 
pr  i  n 
pr  i  n 

i  f  ( 
pp  i  n 
or  i  n 

i  f  ( 
or  i  n 

i  f  ( 
or  i  n 
pr  i  n 

{ 
roos 


51  [2 
ddc  = 


3  = 

1  = 
]  = 

)  = 
]  = 

< 

_  i 

—  i 


]  , ddb , adc  ; 
0  160000  ; 
160000;  ddatOJ 


14  0  0  0  0,* 

i  o  o  o  o  o  ; 

12  0  0  0  0; 

60000; 

)  { 

l  o  o  o  o  o  ; 

)  { 

40000; 

)  { 

20000; 


dda  fl) 
dda  12) 
dda  f33 
dda  [4] 


11  = 
1]  = 
11  = 
1]  = 

n  = 


oo  ; 

020000; 

O6O000; 

040000; 

oi600oo; 


01 


0 

0 
0 

0 
0 

0 
fO] &adb)==ddb 


ddc  =&  077777;} 


ddc  =&  0137777;} 


ddc 


=  &    0157777;} 

&&    (dda  [01  [11 &ddc)=  =  ddc) < 


t  f  (" 
tf  (" 
tf  (M 
(dda 
tf  (M 
tf  (" 
(dda 
tf  (" 
(dda 
tf  (" 
tf  (" 

() 


r  < 
s  < 

R  < 
fl] 
S  < 
R     < 


o    :    " )    ; 

o    :    ")    ; 

o    \n    ")    ;} 
10] &ddb)==ddb 

0    :     ")     ; 

0    \  n    " )     ; } 
[21 [0] &ddb)==ddb 
R    <    0    \n    " )     ;} 
[31  [0] ^ddb)=  =  ddb 
T    <    o    :    ")    ; 

R    <    0    \  n    "  )     ;  } 


> 


&&    (dda  [11  [11 &ddc)=  =  ddc) { 

&&     (dda  [21  (11 &ddc)=  =  ddc) < 
&&    (ada  (31  [11 &ddc)=  =  ddc) < 


FIGURE    4.       Example    Source    Code    from    DELTRANS 
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III.   EXECUTING  YOUR  JOB 


A.   INITIATING  DELTRANS 

The  command  line  for  DELTRANS  has  the  form  of  "deltrans" 
followed  by  the  inout  and  output  filenames*  if  desired. 

If  there  are  no  files  specified,  DELTRANS  will  ooen  the 
standard  input  for  input  and  create  the  file  "d.tab.c"  for 
output . 

If  there  is  only  one  file  name  specified*  DELTRANS  will 
open  that  file  for  input  and  create  the  file  "d.tab.c"  for 
output . 

If  there  are  two  filenames  specified*  DELTRAMS  will  open 
the  first  file  for  input  and  create  a  file  for  ouput  using 
the  second  filename. 

If  there  are  more  than  two  filenames  specified  in  the 
command  line*  the  first  two  are  used  for  input  and  output* 
and  an  error  message  is  produced  alerting  the  programmer 
that  the  system  oetected  an    error     in  the  command  line. 

If  the  programmer  wishes  to  keep  a  record  of  the  format- 
ted  table   summaries  and  error  messages*  he  may  do  so  using 
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the  ">"  and  M ! "  provided  by  UNIX  for  redirecting   the   stan- 
dard output  to  a  file  or  device. 

If  the  code  in  Figure  2  was  in  file  "fig2%  then  the 
command  "del  trans  f  i  c  <?  f  i  g  4  >  fig3"  would  generate  the  out- 
put code  in  file  "fiq4",  and  redirect  the  table  summary  to 
file  "fig3".  Figure  H  contains  the  code  that  would  be  gen- 
erated in  file  "  f  i  g  4  "  and  Figure  3  contains  the  table  sum- 
mary that  would  be  in  file  "  f  i  g  3  "  . 

Since  the  output  from  DELTRANS  is  C  source  code  and  must 
be  compiled  prior  to  execution/  file  names  must  be  of  the 
form  "*.c". 

B.   ERROR  PROCEDURES 

DELTRANS  is  designed  to  detect  a  number  of  errors  during 
execution.  A  list  of  error  messages  is  in  section  IV  of 
this  manual  along  with  sugaested  programmer  response  to 
recover  from  each  error.  The  following  discussion  is 
directed  at  classifying  the  errors  bv  type. 

Ambiguity  and  completeness  checking  results  in  warning 
messages  (program  execution  continues)  when  a  redundant  or 
incomplete  decision  logic  table  is  encountered.  Incon- 
sistent tables  and  act ionless  rules  cause  error  message  gen- 
eration and  DELTRANS  discontinues  processing  of  the   current 
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table.   See  chapter  V  of  the  parent  thesis  for  a   discussion 
of  ambiguity  and  completeness  checking. 

File  errors  are  discovered  by  the  system  and  communi- 
cated to  DELTRANS  for  error  message  generation.  All  file 
errors  cause  immediate  termination  of  preprocessing. 

Errors  in  the  option  section  include  both  numerical 
value  and  syntax.  Value  errors  result  when  invalid  numerals 
(too  larae;  too  small »  improperly  formed)  are  encountered. 
Additionally*  missing  or  duplicate  entries  for  required 
options  cause  error  message  qeneration  and  termination  of 
table  preprocessing. 

Stub  errors  (else/error,  action,  and  condition)  are  nor- 
mally caused  by  exceeding  the  limit  on  stub  length  or 
failure  to  use  the  delimiter,  'a)*,  in  the  proper  place. 
Table  preprocessing  is  terminated  when  a  stub  error  is 
detected. 

Action  and  condition  entry  errors  are  caused  by  either 
syntax  or  invalid  rule  numerals.  Both  of  these  are  fatal 
errors  in  that  preprocessing  of  the  current  table  is  discon- 
t  i  nued. 

Tally  errors  result  when  the  actual  number  of  input 
actions  or  conditions  does  not  aaree  with  the  number  speci- 
fied in  the  option  section.   Because  several  arrays,   inter- 
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nal  to  DELTRANS/  have  been  initialized  using  the  value  in 
the  option  section/  this  error  causes  termination  of  prepro- 
cessing for  the  current  table. 

Numerical  value  errors  can  occur  in  many  sections  of  the 
input.  They  result  from  excessively  large  numerals/  exces- 
sively small  numerals/  or  improperly  formed  numerals.  The 
numerals  are  resized  by  substituting  the  largest  Dermitted 
number  for  that  usage.  An  error  message  is  generated  and 
DELTRANS  attempts  to  continue  execution.  However/  no  output 
code  will  be  generated/  only  error  checking  will  be  per- 
f o  rmed . 

Few  errors  cause  immediate  termination  of  preprocessing. 
Normally  DELTRANS  will  attempt  to  resync h ron i ze  the  input 
stream  and  continue  preprocessing  in  an  attempt  to  generate 
a  formatted  table  for  orogrammer  use  in  debugging.  This 
attempt  to  generate  assistance  for  the  programmer  will 
include  not  only  the  aeneration  of  a  formatted  table/  but 
also  will  include  the  generation  of  some  output  code  when- 
ever possible.  However/  this  is  forced  output/  generated 
only  to  assist  in  debugging.  Seldom  will  executable  code 
result  when  an  error  has  been  detected. 
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C.  CHANGING  THE  INPUT  DATA 

Since  DELTRANS  was  constructed  to  preDrocess  a  file  or 
input  with  multiple  decision  logic  tables  imbedded  in  that 
input*  there  is  no  method  available  to  the  programmer  to 
alter  the  DreDrocessor  actions  other  than  alter  the  input 
data  and  preDrocess  the  data  again.  For  this  reason  the 
programmer  is  strongly  encouraged  to  prepare  the  input  as  a 
file  rather  than  enter  it  from  the  terminal. 

D.  COMPILATION  AND  EXECUTION 

The  output  file  Generated  by  DELTRANS  contains  both  the 
C  code  from  the  input  proaram  as  well  as  the  C  code  gen- 
erated by  the  preprocessor.  In  order  to  execute  the  program 
it  is  necessary  to  compile  trie  outDut  program.  See  the 
applicable  UNIX  reference  manual  for  detailed  instructions 
for  compilinq  and  executina  C  programs. 
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IV.   ERROR  MESSAGES 


A  user  may  receive  one  or  more  error  messages  at  his 
terminal  during  orep rocess i ng •  They  may  cause  immediate 
processing  termination  or  may  only  be  a  warning  to  point  out 
possible  faulty  logic.  In  either  case/  this  section  may  be 
used  as  a  guide  for  error  identification  and  correction. 

All  possible  DELTRANS  error  messages  are  presented  here 
as  they  will  appear  at  the  terminal?  along  with  an  explana- 
tion and  required  user  response.  In  the  event  any  other 
messages  appear  at  the  terminal/  the  UNIX  Progammer's  Manual 
[ 2b)     and  the  C  Reference  Manual  [231  should  be  consulted. 
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A.   WARNING  MESSAGES 


A  list  of  processor  generated  warning  messages  follow. 
Those  not  considered  self-explanatory  are  given  an  error 
number  for  reference. 


EARNING   *****   duplicate  entries  for  number  of  actions. 


WARNING   *****   duplicate  entries  for  number  of  conditions 


WARNING   *****   duplicate  entries  for  number  of  rules. 


WARNING   *****   option  value  less  than  or  equal  to  zero  in 

line  X . 


WARNING   *****   duplicate  rules  specified  for  action  Y  line 

X. 


WARNING   *  A  0  2  *   rules  X  and  Y  in  table  Z  are    redundant 


WARNING   *A03*   table  Z  is  incomplete. 


92 


DELTRANS  USER'S  MANUAL 


B.   AMBIGUITY  AND  COMPLETENESS  ERRORS 


AOl:   ERROR 


*  A  0 1  *   rules  X   and 
si  stent  . 


make   t  ab 1 e 


mcon- 


EXPLANATION: 

In  table  number  Z,  rules  X  and  Y  can  be  speci- 
fied by  the  same  set  of  conditions.  However, 
they  require  different  actions  and  thus  make  the 
table  logic  faulty.  Further  processing  on  table 
Z  was  terminated. 


RESPONSE: 

1.   Examine  carefully  rules  X  and  Y.   Note   that 

all   "don't  cares"  ('-')  can  be  expanded  to  both 

a  "y"  and  a  "n"  entry.   Also  a  "*"  is  equivalent 


to  a  "n"  and  a 
2.   Alter  rules 
error. 


is  eauivalent  to  a  "y". 
and   Y   to   remove   the   loqic 


A02:   WARNING   *A02*   rules  X  and  Y  make  table  Z  redundant. 


EXPLANATION: 

In  table  number  1,  rules  X  and  Y  can  be  satis- 
fied by  the  same  set  of  conditions.  Further- 
more/ they  soecify  the  same  action  and  thus 
either  one  rule  can  be  removed  or  the  two  rules 
combined.  Table  Drocessing  was  not  terminated 
due  to  this  warnino. 
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RESPONSE: 

Remove  the  redundancy   by   either 
rule  or  combining  the  two. 


remov i ng   one 


A03 


WARNING   *A03*   table  Z  is  incomplete. 


EXPLANATION: 

This  warning  is  generated  to  alert  the  user  that 
the  logic  in  table  number  Z  does  not  consider 
all  Dossible  combinations  of  conditions.  In 
addition/  the  else/error  action  is  a  null 
action.  Table  processing  was  not  terminated  due 
to  this  warning. 


RESPONSE: 

1.  Ensure  all  missing  rules  would  only  be 
satisfied  by  impossible  condition  outcomes. 

2.  If  it  can  not  be  shown  that  all  missing 
rules  are  impossible*  enter  an  appropriate  error 
ac  t  i  on  . 

3.  If  all  missing  rules  are  impossible/  ignore 
the  warning.  The  table  output  follows 
presc  ri  bed  1 ooi  c  . 


A04 


ERROR 


*A0U*   no  action  specified  for  rule  X. 


EXPLANATION: 

Internal  ambiguity  checks  reveal  that  rule  X 
no  associated  actions. 


has 


RESPONSE: 

1.  Pecheck  format  and  logic. 

2.  To  implement  a  true  no-action  rule/  incut   a 
null  action  and  specify  that  action  for  rule  X. 
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C.   FILE  ERRORS 


FOl:   ERROR    *F0 1  *   unable  to  open  'd.tab.c'  for  output. 


EXPLANATION: 

UNIX  could  not  open  the  default  output  file 
"d.tab.c"  for  output.  File  errors  cause  termi- 
nation of  preorocess i ng. 


RESPONSE: 

1.  Ensure  prooer  format  of  translator  call  line. 

2.  If  there  are  no  other  program  errors*  contact 
a  consultant. 


F02:   ERROR    *F02*   unable  to  ooen  FILE  for  input. 


EXPLANATION: 

UNIX  coula  not  ooen  the  given   file   for   input. 
File  errors  cause  termination  of  processing. 


RESPONSE: 

1.  Ensure   proper   format   of   translator   call 
line. 

2.  Ensure  given  file  exists. 

5.   If  there  are    no  other  program   errors*   con- 
tact a  consultant. 
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F03:   ERROR    *F03*   unable  to  open  FILE  for  output. 


EXPLANATION: 

UNIX  could  not  open  the  given  file   for   output. 
File  errors  cause  termination  of  processing. 


RESPONSE: 

1.  Ensure   prooer   format   of   translator   call 
1  ine. 

2.  If  there  are  are   no   other   program   errors 
contact  a  consultant. 
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D.   RULE  NUMBER  IN  ACTION  OR  CONDITION  ENTRY 


L01:   ERROR 


*L01*   1 ine  X. 


EXPLANATION: 

The  action  entry  on  line  X  specifies  that  that 
action  is  to  be  performed  for  a  rule  number  that 
is  greater  than  the  maximum  number  of  rules 
declared  in  the  ODtion  section.  Processing  will 
be  terminated  for  this  table  if  the  error  count 
exceeds  the  maximum  allowable. 


RESPONSE: 

1.  Check  the  indicated  line  to  ensure  the  for- 
mat is  correc  t  . 

2.  Check  the  largest  number  in  the  line  against 
the  number  of  rules  specified  in  the  program 
option  sec  t  i  on . 


L02:   ERROR 


*L02*   1 ine  X. 


EXPLANATION: 

A  condition  entry  specifies  a  condition  is  to  be 
tested  for  an  invalid  rule  number.  Processing 
will  be  terminated  for  this  table  if  the  error 
count  exceeds  the  maximum  allowable. 


RESPONSE: 

1.  Check  that  all  rule  numbers  in  the  specified 
entry  line  are  no  larger  than  the  maximum  speci- 
fied in  the  option  section. 
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2.   Examine  line  X  for  format  errors 


L03:   ERROR    *L03*   line  X. 


EXPLANATION: 

A  condition  entry  contains  an  invalid  list  of 
rule.  Processing  will  be  terminated  for  this 
table  if  the  error  count  exceeds  the  maximum 
a  1 1 owab 1 e . 


RESPONSE: 

1.  Check  for  prooer  format  of  line  X. 

2.  Ensure  all  rule  numbers  are  greater  than 
zero . 

3.  Ensure  all  rule  numbers  are  no  larger  than 
the  maximum  rule  number  specified  in  the  option 
section. 

4.  Ensure  the  second  number  in  a  list  is 
greater  than  the  first. 


L04:   ERROR 


*L0a*   line  *  . 


EXPLANATION: 

An  action  or  condition  entry   specifies   a   rule 
number  that  is  not  in  the  specified  range. 


RESPONSE: 

Check  that  all  rule   numbers   in 
entry  line  are    no  larger  than  the 
fied  by  the  program. 


the   spec  i  f  i  ed 
ma x  i  mum  spec  i - 
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E.   OPTION  SECTION  ERRORS 


N01:   ERROR 


*  N  0  1  *   initialization  error. 


EXPLANATION: 

The  number  of  rules?  actions?  and  conditions 
must  all  be  initialized  in  the  option  section. 
In  addition  they  must  all  be  qreater  than  zero. 


RESPONSE: 

Ensure  that  all  rules?  actions?  and  conditions 
are  initialized  and  in  the  proper  format.  The 
number  must  follow  the  option  on  the  same  line 
as  the  opt  i  on . 


N02:   ERROR    *  N  0  2  *   missing  subroutine  name. 

ERROR    *N02*   subroutine  name  missing  from  options. 
ERROR    *N02*   subroutine  name   exceeds   8   characters 
nea r  line  X . 


EXPLANATION: 

The  ootion  section  for  each  decision  logic  table 
must  contain  the  option  nn"  which  specifies  the 
name  of  the  subroutine  into  which  the  decision 
logic  table  will  be  converted.  Processing  of 
the  current  table  is  halted  when  unable  to  find 
the  subroutine  name. 


RESPONSE: 
1  . 


Check  for  proper  format  of  the 


opt  i  on  . 
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2.  Ensure  the  name  is  no  longer  than  8  charac- 
ters and  is  separated  from  the  parameter  list  by 
a  space. 

3.  Ensure  the  name  is  on  the  same  line   as   the 


NO  3 


ERROR 


*  N  0  3  *   unrecognizable  option 


line  X . 


EXPLANATION: 

An  unrecognizable  option  has  been  detected  on 
line  X.  'Q'  is  the  character  DELTRANS  found 
when  it  was  exoect inq  an  option  character. 


RESPONSE: 

1.  Ensure  the  o  r  o  d  e  r  format  is  used.  Notice 
that  no  punctuation,  other  than  spaces,  is 
valid  in  the  option  section. 

2.  See  also  error  N04. 


N04 


ERROR 


*N04*   invalid  numeral  'Q'  near  'P'  line  X. 


EXPLANATION: 

An  invalio  numeral  has  been  detected  on 
following  P . 


1  i  ne 


RESPONSE: 

1.  Ensure  that  the  proper  option  format  is 
used,  includinq  the  circumflex. 

2.  The  number  must  follow  the  option  on  the 
same  line  as  the  option. 

3.  when  the  logic  table  translator  drops  syn- 
chronization in  the  oDtion  section,  error  N03 
and  N04  are  repeated  while  resync ron i za t i on  is 
attempted.  This  is  an  indication  of  invalid 
option  letters,  format,  or  punctuation. 
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N05:   ERROR    *N05*   invalid  number  of  rules  line  X   set   to 

Y. 
ERROR    *N05*   invalid  number  of  actions  line  X  set  to 

Y. 
ERROR    *N05*   invalid  number  of  conditions  line  X  set 

to  Y. 


EXPLANATION: 

The  option  section  of  the  input  program 
requested  that  either  the  number  of  actions* 
conditions?  or  rules  exceed  the  maximum  permit- 
tee by  the  translator. 


RESPONSE: 

1.  A  series  of  small,  linked  tables  are   recom- 
mended . 

2.  Check  line  X  to  ensure  the  option  size  is  as 
needed . 

3.  A  consultant  can  enlarge  the   processor   for 
special  applications. 


N06:   ERROR    *N06*   oeclarations  found  prior  to   subroutine 
name  . 


EXPLANATION: 

The  ODtion  section  must  contain  the  Mn"  toggle 
prior  to  the  "d"  toggle  to  perform  proper  cod- 
ing. No  further  processing  on  the  current  table 
is  at  tempted. 


RESPONSE: 

Edit  the  option  section  of  the  table   and   place 
the  "n"  toggle  before  the  "d"  toggle. 
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N07 


ERROR 


*M07*   invalid  parameter  list 


EXPLANATION: 

The  format  of  the  parameter  list  is  in  error. 
The  translator  has  recognized  and  accepted  the 
name  of  the  subroutine  but  is  unable  to  find  a 
valid  list  of  parameters.  Output  has  been 
forced  into  the  specified  output  file  as  a  pos- 
sible aid  in  debugging. 


RESPONSE: 

Locate  t  he 
the  table 
that  a  "{" 


n'  togole  in  the  option 
and  correct  the  format 
must  be  i  nc 1 uded . 


sec  t  i  on   of 
error.   Note 


N08:   ERROR    *N08*   else/error  syntax  line  X. 

ERROR    * N 0 8 *   missing  else/error  action  line  X. 


EXPLANATION: 

ELSE/ERROR  actions  are  required  for  every  deci- 
sion logic  table  to  be  processed  by  DELTRANS. 
If  no  action  is  desired  a  "  e  A  "  will  set  a  null 
action.  Prooer  format  reauires  that  the  action 
be  on  the  same  line  as  the  toggle  "e". 


RESPONSE: 

Correct  the  format  error  on  line  X. 
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F.   ACTIOIn!  AND  CONDITION  STUB  ERRORS 


SOI:   ERROR    *S01*   invalid  else/error  stub  line  X. 
ERROR    *S01*   invalid  action  stub  line  X. 
ERROR    *S01*   invalid  condition  stub  line   X. 


EXPLANATION: 

An  improperly  formed  stub  has  been  detected. 
Table  processing  is  terminated  when  this  error 
occurs. 


RESPONSE: 

Ensure  proper  format  of  the  stub  on  line  X,  in 
particular  that  the  " 3 "  is  in  position  and  that 
the  stub  contains  no  more  than  31  characters. 


S02 


ERROR 


*  S  0  2  *   invalid  condition  stub  line  X  . 


EXPLANATION: 

FmDty  condition  stubs  are     invalid.    The 
code  will  fail  to  compile  since  a  test  of 
condition  would  be  reoui  red. 


output 
a  null 


RESPONSE: 

Check  the  format  on  line  X. 
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G.   ACTION  AND/OR  CONDITION  TALLY  ERRORS 


T01:   ERROR    *  T  0 1  *   number  of  actions  not  as   specified   in 
opt  i  on  sec  t  i  on . 


EXPLANATION: 

Internal  checks  indicate  the  actual  number  o'f 
actions  input  does  not  eoual  the  number  of 
actions  specified  in  the  option  section.  Table 
processing  has  been  terminated  after  forcing 
table  summary  output. 


RESPONSE: 

Check  the  number  of  actions  and  the  format  of 
the  option  statement.  The  output  table  will  aid 
in  locating  the  error. 


T  0  2  :   ERROR    *  T  0  2  *   number  of  conditions  not 
in  oot  i  on  sec  t  i  on . 


as   soec  i  f  i  ed 


EXPLANATION: 

Internal  checks  indicate  the  actual  number  of 
conditions  input  does  not  egual  the  number  of 
conditions  soecifiea  in  the  option  section. 
Table  processing  has  been  terminated. 


RESPONSE: 

Ensure  that  the  ODtion  number  and  the  format  are 
correct.  See  the  output  table  for  summary 
debugging  assistance. 
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H.   NUMERICAL  VALUE  ERRORS 


V01 


ERROR 


*V01*   excessive  value  line  X  set  to  MAX. 


EXPLANATION: 

An  inteqer  larger  than  any  valid  value  in  the 
translator  has  been  detected.  Further  process- 
ing will  be  attempted. 


RESPONSE: 

1.  Check  inteqer  size  on 

2.  Ensure  Drooer  format 
line  X. 

3.  See   error   N05. 


line  X . 

ud   to   and 


i  n  c  1  u  d  i  n  a 


voa 


ERROR 


*V02*   invalid  numeral  '0'  line  X. 


EXPLANATION: 

An  improperly  formed  strim 
encount  ered . 


of  numerals  has  been 


RESPONSE: 

Ensure  that  all  strings  of  numerals  are  in 
proper  format  and  that  no  characters  other  than 
integers  appear  in  the  string. 
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V03 


ERROR 


*V03*   line  X. 


EXPLANATION: 

A  non-existent  rule  number  appears  in  the  action 
entry  on  line  X . 


RESPONSE: 

Check  all  rule  numbers  in  action  entries 
ensure  that  they  are  greater  than  zero  and 
of  the  prooer  format. 


to 
are 


V04 


ERROR 


*V04*   line. 


EXPLANATION: 

A  non-existent  rule  number  apDears  in  the  condi- 
tion entry  on  line  X. 


RESPONSE: 

Ensure  all  entries  refer       to   positive   non-zero 
rules.   Check  the  format  of  the  condition  entry. 
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I.   SYNTAX  ERRORS 


X01 


ERROR    *X01*   statement  syntax  line  X. 


EXPLANATION: 

A  syntax  error  was   discovered   by   DELTRANS   in 
1 ine  X. 


RESPONSE: 

Review  the  format  uo  to  and  includinq 
indicated. 


the   line 


X02 


ERROR 


*X02*   statement  syntax  line  X. 


EXPLANATION: 

A  syntax  error  was   discovered   by 
line   X.   At  the  time  of  the  error? 


DELTRANS   in 
DELTRANS  was 


attemptinc  to  aecode  a  condition  entry  list. 


RESPONSE: 

Review  the  format 
indicated. 


up  to  and  including   the   line 


X03 


ERROR 


*  X  0  3  *   statement  syntax  line 


EXPLANATION: 

A  syntax  error  was  discovered  by  DELTRANS  in 
line  X.  At  the  t i ^e  the  error  was  detected 
DELTRANS  was  attempting  to  decode  an  action 
entry  list. 
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RESPONSE: 

Review  the  action  list  format  up  to  and 
ing  the  line  indicated. 


i  nc 1 ud- 
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V.   GLOSSARY  OF  TERMS 


Action: 


Something  to  be  done  predicated  on  the 
responses  to  the  conditions  in  the 
table.  May  be  computations*  goto  state- 
ment t     assignment/  etc. 


Action  Entry: 


The  lower  right  quadrant  of  the  table. 
The  only  entry  oermitted  in  this  section 
for  tables  in  limited  entry  format  is  an 
"X".  When  an  "X"  is  placed  opposite  an 
action*  that  action  is  to  be  taken. 


Action  Line: 


One  action  from  the  action  stub  and  its 
associated  list  of  rules  from  the  action 
entry. 


Action  Statement (s) :  The  contents  of  the  action  stub. 


Action  Stub: 


The  lower  left  quadrant  of  the  body  of 
the  table.  Listed  here  are  the  actions 
to  be  taken/  which  depend  on  the  condi- 
tions in  the  condition  stub  above. 
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Comp lex  Rule 


A  decision  table  rule  which  contains   at 
least  one  "don't  care"  entry. 


Condition: 


A  test  or  a  decision  to  be  made  as  part 
of  the  logic  or  Drocessinq  of  a  problem. 
It  should  be  stated  in  a  form  that  may 
be  answered  "yes"  or  "no". 


Condition  Entry: 


The  upper  right  quadrant  of  the  body  of 
the  decision  table.  This  section  con- 
tains resoonses  to  questions  asked  in 
the  condition  stub. 


Condi  t  i  on  Line: 


One  condition  from  the  condition  stub 
and  its  associated  list  of  truth  values 
for  rules  from  the  condition  entry. 


Condition  Statement (s) :  Contents  of  the  condition  stub. 


Condi  t  i  on  Stub 


The  upper  left  quadrant  of  the  body  of 
the  decision  table.  All  the  conditions 
or  tests  to  be  made  will  appear  in   this 


sect  i  on  . 


/ 


Cont  radi  c  t  i  on : 


A  decision  loaic  error  in  which   two   or 
more   rules  have  the  same  combination  of 
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conditions  but   with   different   actions 
specified.   A  synonym  for  inconsistent. 


ELSE  /  ERROR  Rule: 


The  rule  that  acts  as  a  catch-all  for 
all  rules  not  specifically  covered  in 
the  table.  Its  presence  completes  the 
table. 


Ext  ended  Ent  ry 


A  type  of  decision  table  in  which  actual 
condition  values  are  specified  in  the 
condition  entry  part  of  the  table. 


GOTO 


Useo  for  linking  tables/  it  is  an  action 
statement  which  references  another 
table. 


Imposs  i  b 1 e  Rule 


A  rule  that  due  to  dependency  of  condi- 
tions  is  physically  impossible*  e.g.  c  < 
10  and  c  >  20. 


Inconsistency: 


See  contradiction. 


Limited  entry: 


A  tyDe  of  decision  table  in  which  all 
conditions  are  stated  as  guestions  which 
have  a  yes  or  no  answer. 
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A  type  of  decision  table  in  which  both 
limited  entries  and  extended  entries 
appear . 


Recurs  i  on : 


A  synonym  for  looping.  A  conditional 
branch  is  made*  depending  on  a  condition 
value. 


Redundancy : 


A  decision  logic  error  in  which  two  or 
more  rules  have  the  same  combination  of 
conditions  with  the  same  actions  speci- 
fied. 


Rule: 


A  sinale  column  of  the  decision  table 
that  shows  the  combination  of  responses 
to  the  conditions  and  the  resulting  or 
aporocriate  actions. 


Rule  Mask: 


A  method  of  orogram  coding  using  deci- 
sion tables*  where  a  table  matrix  is 
held  in  storage  and  data  matched  against 
i  t  . 


Simple  Rule 


A  rule  which  contains   no   "don't   care" 
entries. 
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Tab  1 e  Li  nkaqe : 


A  conversion  by  which  two  or  more  tables 
are  related  by  means  of  action  transfers 
(such  as  GOTO)  from  one  to  another. 
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APPENDIX  B  -  DELTRANS  SOURCE  CODE 


ne 
ne 
ne 
ne 


ACTLEM 
B I G I N  T 

BLANK 
CDNLEN 
ne  CRLF 
ne  DELIM 
ne  EOF 

ERRLEN 

GNC 

i^ftXRULE 

MAXCDN 

MAXACT 

MAXERR 

NULL 

TAB 

TOKN 

TRUE 

FALSE 


3? 

6a 


// 
// 


%token  COND  ACT  TLIST 
%< 

U 

Ude 

»de 

Ude 

Ude 

Ude 

Ude 

Ude 

ttde 

ude 

ttde 

ttde 

Ude 

ttde 

Ude 

Ude 

Ude 

Ude 

ude 


ALIST  DIGIT  NUM 


max  chars  in  act  stub 
max  integer  in  processor 


ne 
ne 
ne 
ne 
ne 
ne 
ne 
ne 
ne 
ne 
ne 


end 
max 


32 
•\n' 

-1   // 
32   // 
get c ( i  no) 
6a  // 

16   // 
32   // 
5    // 
•NO' 
'\t  ' 

1 
0 


//  max  chars  in  con  stub 


of  file  f  rom  getc ( ) 
chars  in  else/error 
//  used  for  program 


action 
clarity 

maximum  number  of  rules 
maximum  number  of  conditions 
maximum  number  of  actions 
maximum  number  of  non-fatal  errors 


i  n 
i  n 
i  n 
i  n 
i  n 
i  n 
i  n 
i  n 
i  n 
i  n 
i  n 
i  n 
i  n 
i  n 
i  n 
i  n 
i  n 


enum  0;  //  number  of  errors 

inconsis  FALSE?  //  table  inconsistency  flag 

line  1 J  //  line  number 

nexta  0;  //  index  into  action  structure 

nextc  0;  //  index  into  condition  structure 

nodec  TRUE;  //  neaative  declaration  flag 

noelse  TRUE;  //  no  error/else  rule  flag 

noname  TRUE;  //  no  subroutine  name  found 

numact  0;  //  number  of  actions 

numcdn  0?  //  number  of  conditions 

numrule  0;  //  number  of  rules 

parsact  COND  ;  //  parse  action  flag 

pbak  -2;  //  aux  next  character  buffer 

peek  -2;  //  next  character  buffer 

sumact  0;  //  check  sum  on  number  of  actions 

sumcdn  0;  //  check  sum  on  number  of  conditions 

tabno  0;  //  current  table  number 


1  la 


int  rule  [MAXRULE)  ? 
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//   pointers  to  required  actions 
//       for  eac  h  rule 


int  rmasK  [MAXRULE]  [21  ;      //   rule  mask  matrix 
char  eeacttERRLEM  ;    //  error/else  action 


struct  <  //  condition  stubs  and  condition 

char     cltrtCDNLEN);    //  entries 

char     cent  ry  [MAXRULE1  ; 
>cstub  [MAXCDN]  ,  *cpt  r; 


struct  <  //  action  stubs  and  action  entries 

char     al tr  C  A  C  T  L  E  N ]  ; 

char     aent ry  [WAXPULE]  ; 
}astub  [MAXACT]  ,  *aot  r; 


st  rue  t  < 

int      actot  r ; 

int      act  1  trs»' 
>f  ree  (BIGINTJ  ,  *fpt  r  ,* 


/ /  rule  action  lists 


st  rue  t  i  obu  f  r  { 
int  i  ob  f  d  ; 
int  i  o 1 ef  t  ? 
char  *ionxtn  ; 
char  iobuf f [512]  ; 
}     inbuf »  outbuf »  *inp,  *outo; 

%> 
XX 

detab  : 

conha If  act  ha  1 f  ; 

conha 1 f  : 

con  1  i  ne  ! 

conha 1 f  con  1 i  ne  » 

con  1 i  ne  : 

conpart  cdn 1  i  st  ? 

conpart  : 

COND  =  <qetcdn(  )  ;  }  ; 

cdn 1  i  s t  : 

cH  st  '  ; '  =  <  cdn  test  (  )  ; }  ; 


//  both  the  input  and  output 
//  buffers 
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1  ead  : 

logltr  '('  ; 

cdi  g  : 

lead  DIGIT  =  {  fill($2);  $$  =  $2;  >  ! 
coma  DIGIT  =  {  fill  ($2);  $$  =  $2;  }  ', 

cdash  : 

cdig  '-'  DIGIT  =  {  f ill  up ($1, S3)  ;   >  ; 

coma  : 

cdig  ' , '  ! 
cdash  ' , '  ; 

cl i  st  : 

cl  ist  cdig  »)'  I 
cl  i  st  cdash  ' )  •  ; 


1 ogl t  r 

• 
• 

»y« 

= 

{ 

peek 

= 

v '  ;  i 

1  Y' 

= 

{ 

peek 

— 

V  '  '*     } 

•n' 

- 

{ 

oeek 

= 

n  '  ;  } 

•N' 

- 

{ 

peek 

= 

n '  ;  } 

•  *  • 

= 

{ 

peek 

= 

* '  /  } 

•  _  i 

= 

{ 

peek 

= 

-'  i      } 

»$• 

= 

{ 

Deek 

— 

$'  ;  > 

ac  t  na 1 f  : 

ac t 1 i  ne  ! 

ac  t  ha  1 f  act  1 i  ne J 

ac 1 1 i  ne  : 

ac  toart  ac  t  H  st  ? 

actpart  : 

ACT  =  (getactO;); 

act  1 i  st  : 


nl i  st  : 

(MUM  =  {addrul  e($  WSastub  [nexta-1  1  )  ; 

Darsact=ALIST; >    ! 
pal  NUM  =  {addrul e(S2r &astub [nexta-U  )  ; 
parsact  =  ALIST  ;  }  ; 

pal  : 


%% 
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ac  t  est  ( ) 


if  ( 
el  se 
e  1  se 


(peek=eat  a  11  ( ) ) 
parsac t  =  ACT  ? 

if  (oeek==TOKN 
parsact  =  NULL; 
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/*  called  at  the  end  of  each  action 

entry  list  to  determine  what  step 
the  preorocessor  should  take  next  */ 
•=  TOKIM  &&  sumact  <  numact) 


&&    surrac  t  =  =  numac  t  ) 


sumerr("*T01  *","act  ions"); 


addrule  (x*y)  int  x,  y;  {        /*  maintans  rule  pointer 

list  ("rule")*  rule  action 
list  ("free")*  and  action 
entries  in  astub    */ 
int  pt  r ; 
char  *c  ; 

if  (x  >  numrule)  bad  1 og i c (  "LO  1"  )  ; 
else  if  fx  <=  0)  badl ogi c ( " V03" ) ; 
else  if  (*(c=  &apt r->aent ry tx-11 ) i= ' X ' )  { 
*c='X'; 

f pt  r  ->  act  1 trs  =  y  ? 
i  f  (rulelxj  )     { 
pt  r=  f ot  p  ; 
f ot  r  =  ru 1 e  (x)  ; 
while  (fptr  ->  actptr) 

fptr=fptr  ->  actptr; 
fptr  ->  actptr  =  otr? 
f ot  r  =  pt  r ; 
> 
el  se 

rule(x):  f  pt  r  ; 
+  +  f  p  t  r  ; 


>   } 


lse     ( 

printfC" WARNING   *****   auplicate  rules  "); 
printf(" specified  for  action  "); 
printf("%d  line  %d.\nM , x, 1 i ne) ; 
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amb  i  qc  k  (  )   { 


{ 


/*  driver  for  ambiguity 
and  completeness  testing  */ 
i  n t  noamb  i  a»  C  f     k  ; 
noambig  =  TRUE; 

for  (c=0;  c  <  (numrule  -1);  C++) 
i  f  (goodrul e (c  )  ) 

for  Ck=  c+l;  k  <  numrule;  k++)   { 
i  f  (  samerul  e(crk))   { 
amb  i  gt  yp(c  f  k ) ; 
noamb  i  g  =  FALSE ; 


) 


} 


e  1  se 


noambig  =  FALSE? 


} 
i  f 


(goodrule(c)  &&  noambig) 
compl et  e ( ) ; 
re  t  urn ( i  neons  i  s ) ; 


} 


amb  igtyp(Cfk) 
i  nt  n ; 
for 


i  nt  c  ,     k 


{ 


//  determines  type  of 
//  ambiguity  that  exists 
(n=0;  n  <  numact  ;  n++)  { 
if  (astub(n) .aentry  (c)  1=  astubtnl  .aentry  [k]  )  { 
printfC"  ERROR    * AO 1  *   Rules  %d  ",++c); 
printfCand  %d  make  table  %d  "  ,  +  +  k  , 1  abno  )  ; 
print  f ("inconsistent  .\nM)  ; 
i  neons  i  s  =  TRUE ; 
return; 
} 
> 

print f ("WARNING   *A02*   Rules  %d  and  %d  ",++c,++k); 
printf ("in  table  % d  are  redundant. \n",tabno); 


> 


badlogic(c)     char     *c;  {        / /  logic  error  routine 
printf("  ERROR    *%s*  line  %d.\nw , Cr 1 i ne) } 
if  (  +  +  enum  >  MAXERR)  bombO; 

> 

bomb  ()  {  //  excessive  error  exit 

print f(" Processing  of  table  %d  halted  "/tabno); 
printf("due  to  error  count. \n " ); 
k  i  1  1  e  x  (  )  ; 

} 
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cdntest  ()  { 


i  f  ( 
el  se 

> 

el  se 


//  called  at  the  end  of  each 
//  condition  entry  list  to 
//  determine  what  step  the 
//  preprocessor  should  take 

(peek  =  eata1 1  (  )  )  1  =  '  t '  &&  sumcdn  <  numcdn) 

parsact  =  COND; 
if  ( p  e  e  k  =  =  '  T  '  &  &  sumcdn==numcdn)    { 

parsact  =  ACT; 

peek  =  eat  a  1 1  (  )  ; 


sumerr("*T02*","conaitions"); 


} 

compl e 
// 
// 

i  nt 
k  =  0 
for 

i  f 


te() 

unamb 

test  i 

c,  k 

Cc  =  0 

k  =  + 
(k  =  = 
pr  i  n 
pr  i  n 
i  f  ( 


> 


{  //  called  to  determine  if  an 

iguous  table  is  complete.   Completeness 

ng  of  an  ambiguous  table  is  

;  //  ambiguous 

;  c  <  num.ru  1  e  >     C  +  +  ) 

totrule(c) ; 

(1  <<  numcdn))  i 
tfC'Table  %d  is  complete  and  ",tabno)? 
tf("  non-ambiguous. \n"); 
eeact  [0]  !=NULL)  < 

printf(HThe  else/error  rule  for  this  table  ")? 
printf("is  suoerfluous.Xn")? 


} 

el  s 


e  i  f  (eeact  [01 =  =  NULL  )     ( 
print f( "WARNING   *A0  3*   table 
printf(" incomplete. \n"); 


%d  is  "rtabno)» 


}   > 
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cooycode ( 1 t r )   char  ltr  ;   {    //  copy  code  to  output  file 
int  k,  z;  //  up  to  but  excluding  ltr 

whi le( (k=GNC)  >  EOF)     { 
if  (k  ==  ltr) 

ret  urn ( TRUE ) ;  //  normal  exit 

switch  ( k )   { 

case  '"•  :  case  * \ * '  :   //  direct  copy  of  quotes 
put  c ( k , out p ) ? 

whi 1e((z=GNC)  >  EOF  Kl    z  1=  k)   { 
if(z==CRLF)  line++; 

PUt C  ( Z  r OUtp)  ? 
> 

i  f (z  ==  EOF)  thatsi  t (); 
put c ( z ,  outp) ; 
b  reak ; 


case 


/ 


//  comments  are  removed 


k=GNC; 

switch  ( k  )   { 

case  EOF  :  //  EOF 

t  h  a  t  s  i  t  f  )  ; 
case  V  :  //strip  rest 

tossline(k);     //     of  line 
putc (CRLF/outp)  ; 
break ; 
case  '*'  :  //  strip  to  end 

cutcom();        //    of  comment 
b  reak ; 
case  CRLF  : 
1 i  ne  +  +  ; 
default  :  //  normal  case 

putc('/',outp); 
putc(k,outp); 
) 

break ; 
case  CRLF  :  //  count  lines 

1 i  ne  +  +  ; 
default  :  //  normal  case 

put  c ( k / out  p ) ? 
>    } 
return(FALSE) ; 

//  abnormal  exit  (  fail  on  EOF  ) 
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cutcom  ()   {  //  strip  off  comments  up  to  '*/' 

i  nt  c    ? 
whi le  ( (c=GNC)  >  EOF)    { 

if  (c==CRLF)  line++;         / /  count  lines 
else  while  (c==,*,)  {        //  end  of  comment  ? 
if  (Cc=GNC)==CRLF)  line+t; 
else     < 

if  C  c  =  =  '  /  '  )  return; 
i  f  (c==  EOF)  thatsi  t  ()  ; 
>    >    > 


t  h  a  t  s  i  t  (  )  ; 


//  EOF 


> 


decodacr (p / max  /count ) 
char  *p; 

int  max/  *count? 
i  nt  num ; 

if  (*count  1=  0)  { 
print  f ("WARNING 


//  action^  condition/ 
//  and  rule  option 
//  number  decoder 


*****   duplicate  entries  "); 


} 


printf("for  number  of  '/-s  .\n"  ,o)  i 
> 

num  =  gobbleO/  //  number  follows  option 

if(num  <  'O*  Si  num  >  '9')   {    //  if  not  error 

printfC"  ERROR    *N0a*   invalid  M); 

printfC "numeral  ' %  c '  near  %c  "/num/*p); 

p  r  i  n  t  f  (  "  1  i  n  e  %C  .  \ n  "  ,  1  i  n e  )  /' 

if(+  +  enum  >  ^AXERR)  bombO; 

peek  =  num; 

return; 
> 

*count  =  qetvalCnum); 
i  f ( *count  >  max )     { 

printfC"  ERROR    *N05*   invalid  number  of  %s  M/p); 

printfC" line  % c  set  to  %d.\n" /line/max); 

*coun t  =  max ; 

if(++enum    >    MAXERR)     borrbO; 
> 
if     (*count    <=    0)  { 

printfC "WARNING   *****   option  value  less  than  "); 

printfC "or  eaual  to  zero  in  line  %d.\n"/line); 
> 


eatall  C)  { 
i  nt  c  ; 
while  C Cc=qobDleC) )  ==  CRLF  ) 


//  eat  up  blanks/  tabs*  and  newlines 


ret  urn (c  )  ; 


// 


return  the  first  character 
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eatcO  < 
i  nt  c  ; 

i  f  (pbak<0  !  !  pbak==CRLF 

c=eatal 1  ( )  ; 
e  1  se 

c=pbak  ? 
pbak  =  -2; 
return(c); 
} 


i  i 


//  buf  f ered  eat  a  1  1 
//  used  in  yy 1  ex ( ) 
pbak==TAB  !|  pbak==BLANK) 


elserrorO  {  //  decode  else/error  action 

//  and  place  in  eeact U 
if ((eeact 103 =gobbl e C ) )  ==  DELIM) 

eeact [0]  =  NULL; 
else  if  (eeact  [0]  ==  CRLF)   ( 

printfC"  ERROR    *N08*   else/error  syntax  ")? 
printfC "line  7.d.\n",  1  ine)  ? 
if  (t+enum  >  MAXERR)  bombC); 
return; 
> 
e  1  se 

strcooyCERRLEN  -1  ,&eeact  tl]  , "e 1 se /error" ) ; 
noelse  =  FALSE; 
> 

faterr(h»ptr)  int  h;  char  *otr;  {   //  fatal  error  routine 
switch  (h)  { 
case  1  : 

printfC"  ERROR    *F01*   unable  to  open  "),* 
pri  nt  f  ("  '  d.  t  ab.c  •  for  outDut.W); 
b  reak ; 
case  2    : 

printfC"  ERROR    *F02*   unable  to  open  "); 
printf(M,%s'  for  input ,\n",ptr); 
break ; 
case  3  : 

printfC"  ERROR    *F03*   unable  to  ooen  "),* 
printf(MI%s'  for  output .\n",ptr); 
} 

print f ("Execution  terminated  due  to  file  error.  \n" ); 
ex  i  t  ( ) ; 
} 
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fcheckO    { 

char  *uJ 

if  (numrule:=0  ! !  numcdn==0  IS  numact==0) 

U  =  &("\tThe  number  of  "); 

printfC  ERROR    *N01* 

printfC "%srules  is 

printf ("Xscondi t ions  is 

printf ("Xsactions  is 

enum  =  MAXERR  tl; 


> 
i  f 


> 
i  f 


//  check  for  proper  options 

{ 

initialization  error. \n"); 
%  d  .  \  n  " >Ufnumrule) ? 
%d.\n"rUfnumcdn) ; 
%d.\n"fUfnumact ) J 


(noname)  { 
printfC"  ERROR 
p  r  i  n  t  f  (  "  \  n  "  )  ; 
enum  =  MAXERR  ♦!? 


*  N  0  2  *   missing  subroutine  name."); 


i  f 
pee 


( noe 1 se )  < 
printfC  ERROR    *N08*   missing  else/error  "); 
printf(" action  line  Xdi\n"»line)J 
if  (  +  +enum  >  MAXERR)  bombO; 

(enum  >  MAXERR)  bombO; 
k  =  eatal 1  ()  ? 


} 


fill  (c)  Int  c  J  <  //insert 

if  (c  >  numrule)  bad  1 og i c ( "L02" ) ; 
else  if  (c  <=  0)  bad  1 ogi c ( " V 0  4 " ) ; 
else     cotr  ->  centrytc  -  11  =  oeek; 

} 


logic  letter  into 
//    cent  ry 


fill  up  (a/b)  int  a ,b     J     { 

/  /  insert  logic  letter  into  centry  list 
int  i  ; 

if  (a  >  0  &&  a  <=  b  &&  b  <=  numrule)  { 
forCi  =  a;  i  <=  b ;  i++) 

cptr  ->  centry  [i  -  1]  =  peek; 
> 
else     { 

print  fCInval  id  condition  entry:  '%d-%d'\n",  a,  b); 
badlogic("L03") ; 
>   > 
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f  i  ndac  r ( )   < 
i  n  t  c  ; 
whi le  ( (c=qobc() )  >  EOF)  { 
switch  ( c )   { 
case  CRLF  : 

break ; 
case  '  / '  : 

tossline(c); 
break  ; 


//  driver  for  option  decoding 


case 


:  case 


N 


//  end  of  line 

//  rest  of  line  is 
/ /        a  commen t 

://  subroutine  name  follows 


namsub ( ) ? 
break ; 

case  *d '  :  case  ' D • 
i  f  (noname) 


://  only  declarations  remain 
{ 

printfC"  ERROR    *N06*   declarations  "); 

printf(M found  prior  to  subroutine  nan); 

Drintf("me.\nFxecution  terminated. \n"); 

k  i  1  1  e  x  (  )  ; 
} 

peek  =  '  t '  ; 
if  (copvcode (peek ) )  { 

nodec  =  FALSE; 

break  ; 
} 
thatsitO;  //  EOF  encountered 


case  ' r  ' 


case 


//  opt  i  ons 


decodacrC  rules" /MAXRULE,  &n  urn  rule); 

break; 
case  '  c '  :  case  * C  ■  : 

decodacr("condi  t  ions%MAXCDN,&numcdn) ; 

break; 
case  ' a '  :  case  '  A '  : 

decodacr("actions"fviAXACT,&numact); 

break ; 


case 


f  c  h  e  c  k  (  )  ; 
return; 


case 


:  case 


//  end  of  section 

//  check  options  all  defined 

:    //  else/error  action 


e  1  ser ror ( ) ; 

b  reak ; 
def aul t  : 

printff"  ERROR    *N03*   unrecognizable  " ) ; 

pri nt f ("opt i on  '%c'  line  %d . \n" , c , 1 i ne ) ; 

if(++enum  >  MAXERR)  bomb(); 
>    > 
thatsitO;  //  unexpected  end  of  file 
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I 


*N02* 


//  error 

"); 


in  subroutine  name 


f suberr ( k )  i  nt  k 
orintfC  ERROR 
switch  ( k )   { 
case  1   : 

printfC" subroutine  name  missing  from  options"); 
print f(M.\n\nExecut  ion  terminated. \n" )? 
k  i  11  e  x  ( )  ; 
case  2       : 

orintfC" subroutine  name  exceeds  8  characters 

printf ("near  line  "); 

print  f  ("2;d.\nM,  1  ine)  ; 

if(  +  +  enum  >  N'AXERR)  bombO; 


M); 


}  ) 

gencode ( )   { 
genmasks (  ) } 
gen  i  n  i  t ( )  i 
gset mask ( ) ; 


genst  atsO? 
g  e  n  e  o  t  (  )   ; 


//  driver  for  table  outout 

//  code  for  declarations 

//  code  to  initialize  masks 

//  code  to  test  conditions 

//  and  set  mask 

//  output  if-else  statments 

//  outout  end  of  table 


} 


gendub ( )    { 

putc  CCRLFrouto) ; 
put c ( TAB , outp ) # 
putc (TAB, outD) ; 

} 


//    output  CRLF  TAB  TAB 


gene  1 se ( )  { 
gens  i  g ( ) ; 
out code ("else  {"); 

i  f  (eeact  (01  )    < 

gendub ( )  ; 

outcode(&eeact  [0]  ) ; 

putc ( ' ; ' f outp) ; 
} 
else     { 

fptr  =  ru 1 e  [numru 1 e)  ? 

while  (fptr)     { 
gendub (  )  ; 
outcode(fptr->act 1 trs); 

putc( ' ; ' #outp); 

fptr  =  f pt r->ac t pt r; 
>    > 
pUtC ( ' > ' rOUtD) ; 


//  output  else  action 
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geneot ( )    < 

putc (CRLF,outp) ; 

putc ( ' > ' fOutp) ; 

putc (CRLF,outp)  ; 
} 


//  generate  final  M{" 
//  output  subroutine 


for 


qeni  ni  t  (  )  < 
int  c  / 
qens  i  g(  )  ; 

outcode("ddb=0;")  ; 
putc (TAB,outp) ; 
outcode("ddc=  "); 

outoct (01 77777  <<  (16  -  numcdn)); 
out  codeC  ;"); 
for  (c  =  0;  c  <  nunnrule;  C  +  +  )  { 

qensiaO; 

outcodeC'dda  [")  ; 

out  dec  (c  )  ; 

outcodeC'l  [01  =  ")  ; 

out oc t ( rmask  (c J  [01); 

putc ( • ; • , outo) ; 

putc (TAB  t out p) ? 
outcodeC'dda  t")  ', 
outdec  (c ) ; 
outcodeC'l  [11=  "); 
out oc t ( rmask  [cl  fll); 
putc ( ' ; ' , outp)  ; 


//  output  code  to  initialize  masks 


>   } 

genmasks ( )  { 

gens  i  g ( ) 7 

outcodeC'int  ddaf"),* 

outdec (numrul e) i 

outcodeC'l  [21  ,  ddb,  ode  ;  "  )  ; 
> 


//  output  mask  declarations 


gensi  g ( )    { 

putc (CRLF,outp) ; 
putc (TAB, outp) ; 

} 


//  output  CRLF  TAB 


126 


DELTRANS  SOURCE  CODE 


genst  at  s  ( )  { 

i  nt  k  r  nr    i 
i  f  (eeact  10]  ) 

nr  =  numru 1 e  ? 
e  1  se 

nr  =  numru 1 e  - 1 ; 
gens  i  q  (  )  '» 

outcode(Mi f ( (dda [0]  [01 &ddb)=  =  ddb  &&  "); 
outcodeC "(dda  [0]  (11 &ddc)=  =  ddc) {  "  )  7 
f  pt  r=rul e  C 1 ]  ; 
while  (fptr)     { 

gendub ( ) ; 

outcode(fDtr->act 1 t  rs) ; 

fptr=fptr->actptr; 

Dutc ( ' ; • routp) ; 

> 

putc ( ' } ' / out p) ; 

for  (k=l;  k  <  nr  ;  k++)  { 
fDtr=ru1e[k+l); 
gens  i  g ( ) ; 

outcodeC'el  se  if((dda["); 
outdec ( k ) ; 

outcodeC]  [01  &adb)=  =  ddb  &&  "); 
outcodeC"  (dda  [  "  )  ', 
out  dec  (  k  )  ; 

outcodeC'l  U3  &ddc)==ddc){H); 
while  (  f Pt  r )     < 

gendub ( ) ; 

outcode( fctr->act 1 trs) ; 

putc ( ' ; • routp) ; 

fpt  r  =  fpt  r->ac  tpt  r ; 
> 
put  c ( ' > ' t out d) ; 


//  output  if-else  statments 


} 

gene  1 se ( ) » 
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getact  O  { 

i  nt  j  ; 

char  *p; 

p  =  Sastub  [next al  .al t r  [01  ; 

aotr  =  &astub  Inexta  +  t]  ; 

*d  =  peek; 

peek  =  -2; 

i  f  (*pt+  ■  =  DELIM) 

strcopyCACTLEN  -1 , p, "act i on"  )  ; 

e  1  se 

*(--p)  =  null; 

sumac  t  +  +  ; 

Darsact  =  AL 1ST ; 

for  (  j  =  0  ?  j  <  numruleJ  j++) 

aptr->aentry[jl     =    BLANK     ; 
> 


//   fetch  and  store  the  next  action 


getcdn  ()  {  //   fetch  and  store  next  condition 

i  n  t  j  ; 
char  *p; 

p  =  fccstub  Inextcl  .c 1 t r  10]  ; 
cotr  =  &c st ub  [nex t c +  + J  / 
*o  =  peek ; 
oeek  =  -2  ? 
i  f  (*p  ==  DELIM)     { 

printfC  ERROR    *S02*   "); 

printf (" Invalid  condition  stub  line  %d.\n",line)? 

killexO; 
} 

strcopy  (CDNLEN  -h++D/'condi  tion"); 
Sumcdn  +  +  ? 
parsact  =  TLIST; 
for  (j=0;  j  <  numrule?  j+  +  ) 

cpt r->cent ry [ j ]  =  '-'; 
} 
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get  va 1 
int 
num 
wh  i 


} 


(c) 

num 

=  c 

le  (( 

num 

i  f  ( 


i  nt 

9 

-  '0 
c  =  GN 
=  nu 
num 
prin 
pr  i  n 
i  f  ( 
wh  i  1 


i  f  (c 
ret  u 
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//  decipher  a  string  of  numerals 


c  <  = 

'0' 


9')   { 


C)  >=  '0'  && 

m  *  1 0  +  c  - 

>  BIGINT)  { 

tf("  ERROR    *V01*   excessive  value  "); 

tfC'line  %d  set  to  Xd.\nMine,  BIGINT); 

+  tenum  >  MAXERR)  bombO; 

e( Cc=GNC) i=BLANK  R8,  c!=TAB  &&  ci=CRLF) 

if  (  c  ==  EOF  )  that  si  t  ()  ', 

//  find  end  of  number 
==CRLF)  line++; 
rn(BIGINT); 


}  > 

if  (  c  ==  EOF  )  thatsi  t  (  )  ; 

if  (c==B 

if  (c==CRLF) 

1  i  n  e  +  t ; 

return(num); 


//  End-of-f i le 


,LANK  J !  C==TAB) 
{ 


ret  u  rn ( num  )  ; 


> 

pr  i 
pr  i 
i  f 
pee 
ret 


ntfC  ERROR    *V02*   inva");  //  error  exit 

ntf("lid  numeral  :  ' %d%C '  line  %d . \n " , num , c , 1 i ne ) ; 
(++enum  >  MAXERR)  bomb()» 
k  =  c; 
urn ( num  )  ; 


gobble  ()  i  ft    find  first  character  other  than 

int  c  i  ft  a  blank  or  tab 

while  ((c=GNC)==BLANK  !!  c==TAB) 

if  (c==CRLF)  line++; 
el  se 

if  (c  ==  EOF)  thatsi  t  ()  7 
ret  urn (c ) ? 

> 


//  buffered  gobble 
//  used  in  f  i  ndac  r ( ) 


gobc  (  )  < 
int  c  ; 
if(peek  <  0  ) \     oeek==TAB  !!  peek==BLANK) 

c=gobble( ) ; 
el  se 

c=peek ; 
Deek  =  -2r 
ret  urn (c  )  ? 
> 
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goodrule(c)     int  c  7     {         //    each  rule  must  have  at  least 

int  k  ?  //  one  action 

for  (k=0;  k  <  numact?  k  +  +  )   { 

if     (astub  Ik]  .aentry  [cl =='X' ) 
return(TRUE)  ; 

> 

inconsis  =  TRUE; 

printfC  ERROR    *A04*   no  actions  specified  "),* 

printfC'for  rule  %  a  .  \  n  "  ,  +  +  c  )  ; 

return(FALSE) ; 
} 

gset mask  (  )  { 
int  c  $     k ; 


for 


//  output  code  to  test 
//  and  set  test  mask 
numcdn ;  C++ )   { 


condi  t  i  ons 


(c=0;  c  < 
gens  i  g (  )  ; 
outcodeC  i  f  ("); 
outcode(cstub(cl  .cltr); 
outcodeC)  {"); 
gendub ( ) ; 
outcodeC'ddb  =! 
outoct(k=(01  << 
putc ( ' ; ' , outp) ; 
putc ( TAB  t out  p ) ; 
outcodeC'ddc  =& 
outoc  t  ("»k  )  ; 

pUtcCr'fOUtp); 

pUtC  C  •  }  '  ,OUtD)  /* 


" ); 
(15-c))); 


"); 


}   > 


i  n  i  t  var ( )  { 

f pt  r  =  f  ree? 

i  np   =  8-inbuf.iobfd  ; 

outp  =  Soutbu f . i obf d 
} 


//  initialize  variables 


killexO    {  //  kill  execution 

i  nt  c    ; 

f f 1 ush (outp)  ; 

while  ( (c  =  eatal 1  (  )  )  !=  TOKN)     ;    //  attempt  resync 

run  (  )  ; 
} 


ma i n (a rgc / argv  )  int  arqc 
namfi le(argc*arqv); 
if  (copycode (TOKN) )  { 
p  r  o  c  t  a  b  (  )  ; 
run (  )  ; 
> 

f f 1 ush (outp) ; 
} 


;  char  **  argv 
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namend ( )    { 

int  c    ; 

if  C(c=GNC)  ==  EOF)  thatsitO; 

if  (c==BLANK  |!  C==TA8)      return(-l); 

if  (c==CRLF)     { 
1  inen; 
ret  urn ( - 1 ) ; 

> 

return(c); 
} 


//  check  for  end-of -name 


namfile  (argc/argv)  //  fetch  names  for  files 

int  argc  7  //     from  command  line 

char  *arqv  11  J     i 
int  k  i 
i  n  i  t  va  r  (  )  ; 
if(argc  <  2)     i 

if((k  =  fcreat ("d.tab.c" , outp) )  ==  -1) 
faterr(l,arav[0]); 
} 
else  i  f ( argc  ==2)  { 

if((k  =  fcreat ("d. tab. cM,outp) )  ==  -1) 

fat  err ( 1 , arqv  1 1  ]  ) ; 
if((k  =  foDen(argv(l]fino))  ==  -1) 
faterr(2,argv(lJ); 
> 
else  { 

if((k  =  f ooen ( arqv  ( 1 ]  ,  i no  )  )  ==  -1) 

f aterr (2, arqv t 1] ) ; 
if((k  =  fcreat (arqv  12)  route) )  ==  -1) 

faterr(5,arqv t2] ) ; 
if  (arqc  >  3)  { 

printf("  Trash  in  command  line  ::  %s\n",argv[3]); 
}   >    > 


131 


DELTRANS  SOURCE  CODE 


//   copy  subroutine  name  to  output 

//  missing  name 


namsub ( )    ( 

i  nt  c  t     k     ; 

if  ( (c=gobble() )==CRLF)  fsuberr(l); 

putc (c » outp) ; 

noname  =  FALSE; 

for  (k=l;  k  <  9  ;  k  +  + )   { 

if  ( (c  =  namend()  )  <  0)    { 

//  negative  return  indicates  end 


oarm  1  i  s t ( )  ; 

return; 
) 

put  c ( c / ou t  p ) ; 
} 

f  suberr  (.2  )  ; 

wh i 1 e ( (c=namend ( ) )  >=  0) 

parm 1 i  st  (  )  ; 


//  copy  parameters 
//  norma  1  return 


//  name  t  oo  1 ong 


> 


out  ate (c )   i  nt  c    ;    { 

i  n  t  k    ; 

if  (k  =  (c>>3)) 
outate(k); 

putc((c%8  ♦  '  O'JrOUtpJf 
} 


//  output  octal  digits 


outcode(p)  char  *c  ; 
wh  i 1 e ( *p ) 

put  c ( *p  +  + 1 out  p ) ; 
} 


{ 


/ /    output  a  string 


outdec (c )   i  nt  c    ?    ( 
i  nt  k    ; 
i  f  (k  =  c/10) 
outdec  (k)  ; 

pUtC((c%10  +   'OrOUtp); 
> 


//  outDut  a  dec  i  ma  1 


outoc t  (c  )   i  nt  c    ;    < 

int  k,  t     ; 

putc ( '0' ,outp) ; 

if(c>=0)  outate(c); 
else     { 

putc ( ' 1 ' , outp) ; 

c  =  &  (t=077777); 

for  (k=12;  k>=0;  k=k-3)  i 

outc(((c>>k)  +  'O'JfOUtp); 

c  =&  (t=(t>>3)); 

>     }       } 


//    output  an  octal  number 
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//  print  action  stub  and 
//    entry  list 


pact  ( x )  i  nt  x ;  { 

i  n  t  j  ; 

j  =  o; 

print f ("\n%-32.32s3" ,  astub  fx]  ,altr)! 

whileCj  <=  (numrule  -  1)) 

printfC"  %c"r  as t ub t x]  . aent ry  [  j +  +  ]  )  ; 
> 


//  copy  parameter  list  to  output 

{ 


parm 1 i  s t ( )  { 
i  nt  c  ? 
while  ((c=GNC)  >  EOF  *&  c  !=  '{') 

putc (c , out p) ; 

if  (c==CRLF)     line++; 
} 
if  (c  =  ='  {')  ( 

outc ( ' { ' , outo) ; 

putc(CRLFfOutp); 

return ; 
} 
printfC  EPROR    *N07*   invalid  parameter  list.Xn"); 


thatsitC); 


} 


pcond  ( x )  i  nt  x ;  { 

i  n  t  j  ; 

j  =  o; 

print f ("\n%-l2. 12s*" ,    cstub  txl  .cltr)? 

whileCj  <=  (numrule  -  1)) 

print f("  %c"f  cstub  [xl  .cent ry t j +  +  ]) ; 
} 


//  Drint  condition  stub 
//  and  entry  list 


proc  t  ab ( )   { 

t  a  b  n  o  +  +  ; 

f  i  ndac  r  (  )  7 

i  f  ( yypa  r se  (  )  ) 
return; 

yyaccot ( ) ; 
> 


//  process  table 
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ptable  ( 
i  nt  i 
print 
print 
print 
print 
print 
print 
f  or  (  i 
print 
f  or  (  i 
print 
i  f  (n 

p 
el  se 

P 
e  1  se 

P 
print 


)  {  //  driver  to  print  table 

f("\nTABLE  SUMMARY  FOLLOWSW )  ; 

f("\nTA8LE  NUMBER      %d  .  Sn"  ,  t  abno  )  ', 
f ("number  of  conditions  =  %  d  \  n  "  ,  numcdn); 
f ("number  of  rules       =  %  d  \  n  " ,     numrule); 
f ("number  of  actions     =  %  d  \  n  "  ,  numact); 
f  (M\n%sX29s\n%  "CONDITIONS:",   "RULES:"); 

=  0;  i  <=  nurrcdn  -  l;  i++)  pcond(i); 
f  ("\n\nACTIONS:\n")  ', 

=  0;  i  <=  nurract  -  1;  i++)  pact(i); 
f("\nH); 
oe 1 se) 

rintf("****  MISSING  ELSE/ERROR  ACTION  ****"); 
i  f  (eeact  101  ) 
rintf ("ELSE/ERROR  ACTION  :  %s " , &eeac t  [0]  )  ; 

rintfC"****  NULL  ELSE/ERROR  ACTION  ****"); 
f  (  "  \  n  "  )  ; 


//  reinitialize  variables 


rei  n  i  t  (  )    ( 
i  nt  c    ; 

enum  =  nexta  =  nextc  =  numact  =  0? 

numcdn  =  numrule  =  sumact  =  sumcdn  =  0? 

noelse  =  nodec  =  noname  =  TRUE? 

i  neons  i  s  =  FALSE; 

parsact  =  COND; 

pbak  =  Deek  =  -2 ; 

f pt  r  =  f  ree; 

for  (c=0;  c  <  MAXRULE  ;  C++)     { 

rulefc)  =  rmasktcMO]  =  rmasklcl  111  =  0; 
> 
for  (c=0;  c  <  BIGINT  ;  C++)  { 

free  lei  .actptr  =  f reefel  .actl trs  =  0; 
>   } 


run()   {  //  driver  for  multiple  table  coding 

while  (copycode(TOKN) )   { 
rei  n  i  t  (  )  ; 
proc  t  ab  ( )  ; 
} 

f flush (out p); 
e  x  i  t  (  ) ; 
} 
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sameru 1 e ( a r b )   int  a,    b;    { 
char  n ,     p? 
int  k; 

k  =  -i; 

while  (k++  <  numcdn)      { 

n  =  c s t ub  [  k3  .cent ry f al  ; 
p  =  est ub tk]  .cent ry tb]  ; 
switch  (n)   { 


//  t  est  if  rule  a  and 
//  rule  b  are  identical 


case 


break ; 


case  ' y ' 


case 


$ 


if  (pss«n'!Jpss«*«J 

return(FALSE)  ', 
break ; 

case  '  * '  : 
i  f  (pss'y'  !  !p=='$' ) 
return(FALSF)  ', 
}    } 
return(TRUE) ; 


} 


//    set     rule    masks 


setmask     ( )     { 

int     ir     \  >     orlist; 

orl i  st    =    1 ; 

for(i     =    0;i     <    numcdn;i++)  { 

for(j     =    0;j     <    numrule/j++)        { 
orlist     =<<     (  15-i  ) ; 
switch     (cstubtil.centry(jJ)     i 
case    * y '     :       case     ' J '     : 

rmask  [  j 1  10]     =!     orlist; 
break ; 
case     '  n '     :       case     ' * '     : 

rmask  [j][l]     =!     orlist; 
break ; 
def aul t     : 

rmask  ( j 1  [0]     = !     orlist; 
rmask  [jl  [1]     =!     orlist; 


> 

orlist    =    1 ; 


}       > 
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st rcopy ( k , p, s )  int  k?  char  *p,  *s?  { 
int  i»  c     ;  // 

i=o   ; 

whi  1  e  (++i  <  k)  { 

if  ((c=GNC)  ==  DELIM)    break; 

if  (c==CRLF)     line++; 

else  if  (c  =  =  EOF)    thatsitO; 

*p++=c; 


//  copy  string 
from  input  to  P 


> 

*P 
i  f 


=  null; 

(i>=k  £&  (c=GNC) 
if  (c==  EOF) 
printfC  ERROR 
printf("Inval ia 
killexO; 


1=  DELIM)    { 
thatsitO; 

*soi*  "); 

%s  stub  line  %d.\n",s,line); 


>   > 


suTierr(n»c)  char  *n,  *c;    {  //    print  number  errors 

printfC  ERROR    %s   number  of  %s  not  ",n,c); 

printf("as  SDecified  in  notion  section. \n"); 

printf ("\nExecut  ion  terminated. \n" ) ; 

k  i  1  1  e  x  O  ; 
> 

thatsitO  {  //   exit  for  invalid  end-of-file 

print f ("Unexpected  END  OF  FILE  encountered,  "); 
printf ("execution  terminated. \n"); 
f f 1 ush (outp) ; 
e  x  i  t  ()  ; 

> 

tossline  (c)  int  c  ;  {     / /   toss  away  rest  of  line 

if  (c!=CRLF)  while  ( (c=qobb 1 e () ) 1 =CRLF )  ; 
} 


totrule(n)  int  n;   { 
int  k ,     t ; 

t  =  o; 

for  (k=0;  k  <  numcdn  ;  k  +  +  )  { 

if  (cstub(k)  .centry(n)  ==  '-') 

t  +  +  ; 

} 

return(l  <<  t); 
> 


//  sum  the  number  of  simple 
//  rules  in  a  table  rule 
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yyaccpt  (  )  { 

i  nt  i  ; 

ptable  (); 

i  f  (enum ) 

return; 

i  f  (ambi  gc  k  ( )  ) 
return ; 

setmask  (  )  ; 

gencode ( ) ; 
} 


//  accepted  table  routines 


yyerror(s)  char  *s  ;    {        //  syntax  error  handler 
printfC  ERROR    *X0"); 
if  (parsact  ==  TLIST) 

ppintfC"2"); 
else  if  (parsact  =  =  ALIST) 

p  r  i  n  t  f  (  "  3  "  )  ; 
e  I  se 

printfC" 1 " ) ; 
printf("*   statement  syntax  line  Xd.\n" J  ine)» 
killexO; 
} 


/  /  scanne  r 


//  flag  for  scanner 


yy 1  ex ( )  { 

extern  i  nt  yy 1 val i 
i  n  t  c; 

switch  (parsact)  { 
case  TLIST 
case  ALISF 
case  NUM 
case  DIGIT 

i f  (  (c=eatc())  >=  '01  &&  c  <=  (9')  { 
yylval  =  c  -  '0'  ; 

while  ((c=GMC)  >=  '0'  &&  c  <=  '9')  { 
yylval  =  yylval  *  10  +  c  -  '0'  } 
ifCyylval  >  numrule)  bad  1 og i c ( "L04 " ) ; 
> 

if  ((pbak  =  c)  ==  CRLF)  line++; 
e  1  se 

i  f  (c  =  =  EOF)  thatsi  t ( ) ; 
parsact  =  (oarsact  ==  ALIST  ?  NUM  :  DIGIT); 
ret  urn (parsact ) ; 
} 

ret  urn (c ) ; 
def aul t  : 

return(parsact  )  ', 
)        > 
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